duncan@helium.siesoft.co.uk (Duncan McEwan) (02/07/90)
parmelee@wayback.cs.cornell.edu (Larry Parmelee) writes: >In article <2601@xyzzy.UUCP> pafford@rtp.dg.com writes: >> One thing I don't understand is the setting of the options to the name >> server resolver functions. In particular, the options RES_DEFNAME and >> and RES_DNSRCH are turned off before calling getmxrr() in deliver(). >> Why? > >My guess is that it's an optimization, This was my guess too, but I would be happier if someone "in the know" could confirm it. I found that with sendmail turning off RES_DEFNAME and RES_DNSRCH, ruleset 3 could rewrite header addresses differently than envelope addresses. This happens because S3 is run over envelope addresses with RES_DEFNAME and RES_DNSRCH enabled, but over header addresses with them disabled. (deliver() turns them off, then initiates the call sequence smtpdata() -> putheader() -> commaize() -> remotename(), which results in the header addresses being run through the appropriate rulesets and output). I felt that different rewriting for envelopes versus headers by S3 was unintuitive so I moved the turning off and reinstating of those resolver capabilities to just around the call to getmxrr(), though at the time I couldn't see any reason for not just getting rid of them altogether. per@erix.ericsson.se (Per Hedeland) writes: >This was hashed over at some length when 5.61 was released; I believe the >consensus was that it is a safeguard against incorrect matches when there are >wildcard MX records in or above the default domain. I don't understand why the unsetting of RES_DEFNAME and RES_DNSRCH before doing a getmxrr() call is a protection against wildcard MX records. If that is the purpose, could someone perhaps explain it? There is certainly a comment in "conf.h" above the define of NO_WILDCARD_MX to the effect that if such RR's exist, sendmail cannot ask for records of type T_ANY in the routine getcannonname() (in domain.c) -- rather it asks for records of type T_CNAME. If my understanding of the way the DNS and the 4.3 resolver routines work, only asking for T_CNAME records is a somewhat more limiting way of obtaining the cannonical name for a given host, since it relies on a CNAME record existing for the host you are looking up. In general, this will not allow sendmail to use "getcanonname" (which is called whenever '$[' is in the .cf file) to expand partial names to fully qualified ones (I know that there are arguments as to whether that is the job of the MTA or the UA). If on the other hand you allow query's for T_ANY records, then the res_search call that getcanonname() makes will use the DNSRCH and DEFNAME features to return a fully expanded name for a partial name within your DEFNAME even though there is no CNAME record to do that mapping. The disadvantage is, as the comment in the code points out, that if the first record that res_search returns is an MX record you will canonicalise the name incorrectly (For eg, you could end up "canonicalising" "siesoft.co.uk" to "ukc.ac.uk", which is not exactly the desired result! But if this is the only disadvantage, getcanonname should be able to cope with it by doing a res_search() for T_ANY records, and ignoring any MX's returned in response. Any comments? Duncan