knutson@weber.sw.mcc.com (Jim Knutson) (04/13/91)
I've been trying to trace down a problem I've been having with name
canonicalization using $[ $]. I want to be able to resolve host.sub
into host.sub.top.domain or host into host.top.domain.
For example, my domain is sw.mcc.com. I want to be to send:
user@act -> user@act.mcc.com
and
user@bc.cad -> user@bc.cad.mcc.com
The $[$] rewrite won't do this. This isn't so much of a problem for
mail delivery since the IPC mailer CAN resolve these host names. The
real problem is that because you CANNOT resolve these in ruleset 0,
your mailer choice (and hence your header rewriting) will be affected.
In this case, these hosts look like external domain hosts (not part of
mcc.com) and the headers are rewritten accordingly.
The reason this is happening is because maphostname() turns off
recursive domain name matching (RES_DNSRCH) before calling
getcanonname(). The reason given for this is as follows:
/*
** Don't do recursive domain searches. An example why not:
** Machine cerl.cecer.army.mil has a UUCP connection to
** osiris.cso.uiuc.edu. Also at UIUC is a machine called
** uinova.cerl.uiuc.edu that accepts mail for the its parent domain
** cerl.uiuc.edu. Sending mail to cerl!user with recursion on
** will select cerl.uiuc.edu which maps to uinova.cerl.uiuc.edu.
** We leave RES_DEFNAMES on so single names in the current domain
** still work.
**
** Paul Pomes, CSO, UIUC 17-Oct-88
*/
Now, what I really want to know is whether or not this is a valid
argument. I think that resolving uucp names into internet names using
the domain name service is wrong. The latest config files take steps
to avoid doing this. Even if the uucp name is being resolved, the
canonical uucp form of host!user is user<@host.uucp> which shouldn't
resolve as described above. So why not turn it back on and allow mail
addresses to be resolved in a consistent manner with hostname lookups?
--
Jim Knutson
knutson@mcc.com
cs.utexas.edu!milano!knutson
Wk: (512) 338-3362rickert@mp.cs.niu.edu (Neil Rickert) (04/13/91)
In article <3006@weber.sw.mcc.com> knutson@weber.sw.mcc.com (Jim Knutson) writes: >I've been trying to trace down a problem I've been having with name >canonicalization using $[ $]. I want to be able to resolve host.sub >into host.sub.top.domain or host into host.top.domain. >For example, my domain is sw.mcc.com. I want to be to send: >user@bc.cad -> user@bc.cad.mcc.com >The reason this is happening is because maphostname() turns off >recursive domain name matching (RES_DNSRCH) before calling >getcanonname(). The reason given for this is as follows: >Now, what I really want to know is whether or not this is a valid >argument. I think that resolving uucp names into internet names using 1. You should have identified this as an IDA version of sendmail. In the standard Berkeley versions RES_DNSRCH is not turned off. 2. Here is a good reason for turning off RES_DNSRCH: Suppose someone in your French department has a machine called eiffel.fr.mcc.com. (OK. You aren't a University, and you don't have a French Department. But let's pretend here for a moment.) Now imagine you wish to send a message to 'user@eiffel.fr' -- the real eiffel.fr, that is, in France. You can't if RES_DNSRCH is turned on, because it will always go to your French department. 3. You do have a good alternative. With the IDA package, just define DOMAINTABLE, and you can translate anything into anything. This differs from RES_DNSRCH in that you have deliberately chosen which name to translate, rather than it depending on the accident of what new machines have been defined in a parent domain. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
karl.kleinpaste@osc.edu (04/13/91)
rickert@mp.cs.niu.edu writes: You should have identified this as an IDA version of sendmail. In the standard Berkeley versions RES_DNSRCH is not turned off. Not true, Neil. From raw sendmail-5.65/src/deliver.c: deliver(e, firstto) { ...lots 'n lots o' preparatory gunk... #ifdef NAMED_BIND _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ #endif ...assorted other delivery stuff... #ifdef NAMED_BIND _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ #endif ...final delivery status checking... } Sure looks turned off to me... --karl
ddean@rain.andrew.cmu.edu (Drew Dean) (04/14/91)
In article <1991Apr12.235346.28444@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: | 2. Here is a good reason for turning off RES_DNSRCH: | Suppose someone in your French department has a machine called | eiffel.fr.mcc.com. (OK. You aren't a University, and you don't | have a French Department. But let's pretend here for a moment.) | Now imagine you wish to send a message to 'user@eiffel.fr' -- the | real eiffel.fr, that is, in France. You can't if RES_DNSRCH is | turned on, because it will always go to your French department. | Neil W. Rickert, Computer Science <rickert@cs.niu.edu> I'm not a real sendmail hacker (I got 5.61 working on my machine and quit at that), but if you can't send mail in this case to user@eiffel.fr. <-- note the final period !, then sendmail is _really_ broken. The final period is defined to indicate this is a complete domain name, and should not be expanded -- otherwise, think of the problems with Czechoslovakia having the domain .cs -- how much mail would ever escape the local CS departments ? :-) [Alas, I'd say some systems probably do have this problem, but it seems (in general) that CS departments do a better-than-average job of system administration....] -- Drew Dean Drew_Dean@rain.andrew.cmu.edu [CMU provides my net connection; they don't necessarily agree with me.]
rickert@mp.cs.niu.edu (Neil Rickert) (04/14/91)
In article <12665@pt.cs.cmu.edu> ddean@rain.andrew.cmu.edu (Drew Dean) writes: > >I'm not a real sendmail hacker (I got 5.61 working on my machine and quit >at that), but if you can't send mail in this case to user@eiffel.fr. <-- >note the final period !, then sendmail is _really_ broken. The final period RFC1123 specifically warns that addresses with a final period are INVALID. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
ylee@csl.dl.nec.com (Ying-Da Lee) (04/16/91)
In article <12665@pt.cs.cmu.edu> ddean@rain.andrew.cmu.edu (Drew Dean) writes: >In article <1991Apr12.235346.28444@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >| 2. Here is a good reason for turning off RES_DNSRCH: >| Suppose someone in your French department has a machine called >| eiffel.fr.mcc.com. (OK. You aren't a University, and you don't >| have a French Department. But let's pretend here for a moment.) >| Now imagine you wish to send a message to 'user@eiffel.fr' -- the >| real eiffel.fr, that is, in France. You can't if RES_DNSRCH is >| turned on, because it will always go to your French department. > >I'm not a real sendmail hacker (I got 5.61 working on my machine and quit >at that), but if you can't send mail in this case to user@eiffel.fr. <-- >note the final period !, then sendmail is _really_ broken. The final period >is defined to indicate this is a complete domain name, and should not be >expanded... In article <1991Apr14.002726.9334@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > > RFC1123 specifically warns that addresses with a final period are INVALID. I think Drew made a very valid point. People who know enough to put an ending priod should have their words respected. Furthermore, RFC 1123 (I assume it's the last item of section 5.2.18 that Neil is refering to) does not automatically comes into play here. It states Some systems over-qulaify domain names by adding a trailing dot to some or all domain names in addresses or message-ids. This violates RFC-822 syntax. It would be a clear violation of RFC-822's syntax if a mailer used user@eiffel.fr. as the recipient address on the envelop. Still, there is no reason why the mailer couldn't resolve an input of 'user@eiffel.fr.' into host 'eiffel.fr.' (with ending period) and recipient 'user@eiffel.fr' (without ending period). Only the sending system and DNS, which routinely accepts ending period in a domain name, see the host part. Nowhere else is it used in the e-mail. This way, people in mcc.com can send mail to France with user@eiffel.fr. (with period) and to its own French department with user@eiffel.fr (without period). Ying-Da Lee (214)518-3490 C&C Software Development Lab NEC America (214)518-3990 (FAX) ylee@csl.dl.nec.com uunet!necbsd!ylee
pallas@eng.sun.com (Joseph Pallas) (04/16/91)
In <1991Apr14.002726.9334@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > RFC1123 specifically warns that addresses with a final period are INVALID. RFC1123 says this (5.2.18): o Some systems over-qualify domain names by adding a trailing dot to some or all domain names in addresses or message-ids. This violates RFC-822 syntax. and this (6.1.4.3): (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method. How is this possible? Easy. Section 5.2.18 is talking about SMTP, while Section 6.1.4.3 is talking about user interface. In 5.2.18 we are told that ONLY fully qualified domain names may be used in SMTP by an Internet host, so there is clearly no need to distinguish names that are not fully qualified. Conclusion: If you accept mail addresses with host names that are not fully qualified, then you had better turn them into fully qualified names before passing them on. And if you do accept abbreviations, you'd better provide a convention for overriding them. So, in our hypothetical example, the user can send mail to "user@eiffel.fr" or to "user@eiffel.fr.", and the mail will go to (822-address) "user@eiffel.fr.mcc.com" or to (822-address) "user@eiffel.fr", as appropriate. joe
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (04/16/91)
ylee@csl.dl.nec.com (Ying-Da Lee) writes: >(stuff about trailing '.' in email addresses deleted) > >This way, people in mcc.com can send mail to France with >user@eiffel.fr. (with period) and to its own French department with >user@eiffel.fr (without period). This is exactly the reason RES_DNSRCH should be turned off. Sure you can distinguish the systems with a trailing '.'. How do you intend to communicate this bit of magic to the ordinary users? Far better to train them to use FQDNs so that mail works as expected and they can learn from their mistakes. Violating the Principle of Least Astonishment has no pay-off with systems used by everyone in the organization. /pbp -- Paul Pomes UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910
rickert@mp.cs.niu.edu (Neil Rickert) (04/16/91)
In article <1991Apr15.200923.11004@csl.dl.nec.com> ylee@csl.dl.nec.com (Ying-Da Lee) writes: > >In article <1991Apr14.002726.9334@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> >> RFC1123 specifically warns that addresses with a final period are INVALID. > >Furthermore, RFC 1123 (I assume it's the last item of section 5.2.18 >that Neil is refering to) does not automatically comes into play here. >It states > Some systems over-qulaify domain names by adding a trailing > dot to some or all domain names in addresses or message-ids. > This violates RFC-822 syntax. > >It would be a clear violation of RFC-822's syntax if a mailer >used user@eiffel.fr. as the recipient address on the envelop. But this is exactly the point. If you allow 'eiffel.fr' to mean that it should be qualified in the local domain, but 'eiffel.fr.' to mean it should not, then consider what happens: A user on your system sends mail to 'user@eiffel.fr.' with the final period meaning it should not be qualified locally. Your mailer removes the final period on the envelope address, as you stated. It is relayed to 'host.other.domain'. Since there is no longer a final period, if this relay host follows your philosophy it will attempt to qualify 'eiffel.fr' in its own local domain. Worse still, because of the possible use of MX records, you can never know where you are relaying mail. The reliable approach is to NEVER allow addresses such as 'eiffel.fr' to be locally qualified. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
ylee@csl.dl.nec.com (Ying-Da Lee) (04/16/91)
Yup, I got carried away in my conclusion when I said This way, people in mcc.com can send mail to France with user@eiffel.fr. (with period) and to its own French department with user@eiffel.fr (without period). Neil is absolutely right in saying The reliable approach is to NEVER allow addresses such as 'eiffel.fr' to be locally qualified. On the other hand, the main point of argument in my message, namely, Furthermore, RFC 1123 ... does not automatically comes into play here. ... there is no reason why the mailer couldn't resolve an input of 'user@eiffel.fr.' into host 'eiffel.fr.' (with ending period) and recipient 'user@eiffel.fr' (without ending period). still holds, and that address eiffel.fr. specified by the user should not be rejected. It is the same point that pallas@eng.sun.com (Joseph Pallas) made in his posting. The 'Principle of Least Astonishment' that Paul Pomes brought up would, in fact, demand this treatment: In almost all other interactions with DNS on practically all implementations, eiffel.fr. is THE sure way to get you to France without any surprises. Ying-Da Lee (214)518-3490 C&C Software Development Lab NEC America (214)518-3990 (FAX) ylee@csl.dl.nec.com uunet!necbsd!ylee
piet@cwi.nl (Piet Beertema) (04/16/91)
>So, in our hypothetical example, the user can send mail to >"user@eiffel.fr" or to "user@eiffel.fr.", and the mail will go to >(822-address) "user@eiffel.fr.mcc.com" or to (822-address) >"user@eiffel.fr", as appropriate. Only "user@eiffel.fr" is appropriate here, as per RFC822, section 6.2.2. Either you allow 2-letter subdomains that - now or in the future - coincide with official top level domains, but then you have no choice other than not allowing abbreviated addresses. Or you don't allow 2-letter subdomains and leave open the option of allowing abbreviated addresses. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl)