lynch@spiff.stanford.edu (William Lynch) (05/26/90)
I can't believe we're the only ones with this problem. We're running 3.1/2.2 on DECstations, and when using BIND, binmail really blows using MX records for mail which should be forwarded through some remotely local site (did I say that?). Here's the good part though: it works fine if bind is the FIRST thing in the /etc/svcorder file! I suppose that binmail looks in the svcorder file (the string is in the executable, anyway) to see if you are BINDing, but somehow figures it doesn't need MX records unless bind is the first thing in the file (?). We of course have a workaround of putting bind first in the svcorder file, but the number of other things that breaks due to local aliasing is rather impressive. Does anyone have any other ideas/fixes/causes? Can anyone empathize? Does anyone know if this is fixed in 4.0 (we did report it)? Bill lynch@umunhum.stanford.edu PS our VAXstations don't have this problem.
avolio@decuac.dec.com (Frederick M. Avolio) (05/26/90)
In article <631@helens.Stanford.EDU> lynch@spiff.stanford.edu () writes: > >I can't believe we're the only ones with this problem. We're running >3.1/2.2 on DECstations, and when using BIND, binmail really blows using MX >records for mail which should be forwarded through some remotely local site >(did I say that?). Here's the good part though: it works fine if bind is >the FIRST thing in the /etc/svcorder file! I had reported this bug a while ago. I am told by a few customers of mine who tested this on FT 4.0 that it is fixed, so ULTRIX 4.0 should fix this. It was do to a programming logic error when trying to handle the service order (which I think is a great feature). We had local then bind listed and where not able to send mail to hosts hat had no address record but did have an MX record. Bascically, what you described we saw and I am told it is fixed. Fred