Craig_Everhart@TRANSARC.COM (05/24/91)
Thanks for your notes. I hope we can make progress on this. Excerpts from mail: 24-May-91 AMDS oddities Christer Bernerus@ctp.se (1391+0) > 1. The BBD script sends me lots of mail telling me that everything is > OK, I'm drowning in this and I'm unable to sort out what is important > and what isn't. We've used the BBD script to send messages to bboard folders. That's what the LogBB and DaemonBB addresses are for: prefixes that will get mail sent to folders. For example, there's a local pseudo-user ~bb here at Transarc. We set DaemonBB to ``bb+transarc.system.daemons'' and LogBB to ``bb+transarc.system.postman.logs''. This gets the BBD-generated messages to create folders under transarc.system.daemons and transarc.system.postman.logs. Several folders get one message a day. Most of it is simply saying that everything is OK, but those folders get purged weekly (by another BBD job). It takes me about 5 minutes a day to look over the set of automatic posts. > 2. The file ~postman/Addrs/Addrs is never created in the configuration > process, and the newaddr.csh script assumes there is such a file. If > not, the newaddr.csh script fails in the final sort, but no Addrs file > is ever created. This is a bug. I'll submit a patch to fix it. Creating the ~postman/Addrs/Addrs file should fix it, as you noticed. It's a bug in pobb-install.pobb. > 3. Setting AMS_DeliveryViaDomainMXAddress to Yes causes AMDS validation > to append ".ctp.se.ibm.com" to every To: address on email we write and > thus disables all email to the outer world. You've got a wildcard MX record for *.ctp.se.ibm.com (pointing to ibmns.ctp.se.ibm.com and chalmers.se). Your resolver sets a default domain of ctp.se.ibm.com (perhaps because that domain is a trailing domain for the name of your PO machines). Your resolver also sets the RES_DEFNAMES and the RES_DNSRCH flags by default, so that every name given to the resolver is checked for being an abbreviation by having default domains appended to it. In the case of, say, andrew.cmu.edu being checked on PO machine who.ctp.se.ibm.com, what will happen is that the resolver checks whether andrew.cmu.edu.ctp.se.ibm.com exists (either in an A record or an MX record); failing that, it checks andrew.cmu.edu.se.ibm.com, then andrew.cmu.edu.ibm.com, then andrew.cmu.edu. In your case, the first check succeeds, since andrew.cmu.edu.ctp.se.ibm.com has a valid MX record, matching *.ctp.se.ibm.com. This will certainly happen on your PO machines, since they have names ending in .ctp.se.ibm.com. Does it happen on your workstations also, since they have names ending in .utc.chalmers.se, and there's no wildcard MX record for *.utc.chalmers.se? I believe that getting rid of the wildcard MX record, or renaming all PO machines and relevant workstations so that they don't have names ending in .ctp.se.ibm.com, will eliminate this behavior. Eliminating RES_DNSRCH or RES_DEFNAMES from your resolver debug configuration would do that, too. Bigger wrenches would involve dinking with overhead/mail/lib/rsearch.c itself. > 4. I still cannot send mail to domains who requires MX address (maybe > because I haven't set the variable above) Yes, it's because you haven't set AMS_DeliveryViaDomainMXAddress. > 5. Lots of scripts redirect their output to /dev/console. Now, if anyone > logs in on the console ans anything but postman, the login program will > change the owner of /dev/console to whoever logged in, and thus > /dev/console will be unavailable for postman, thus causing the scripts > to fail and DIE. This is found by the cron job within an hour, and the > machine is rebooted thus causing a lot of irritation, especially if it > happens to the machine which is also our IP router to the rest of the > world. I still think that these daemons should run as root, but with AFS > ticket to "postman". This would also eliminate the need for a special su > since pagsh+klog would do the trick. Good idea. I don't know what system type your PO machines are; we at Transarc found that on RTs running AOS 3, login didn't set the permission bits on /dev/console, but that when they ran AOS 4 (the December 1988 release), login set those permission bits. Thus, our single PO machine has a message taped to it reading something like ``Do not log in on the console of transarc.com unless you are prepared to restart the mail system.'' It would probably work to run these daemons as root, AFS-authenticated as postman. Thanks, Craig