Our outbound mail is everything from mail to Outlook clients to automated pages and alerts. Since it originates in VM, it will still be allowed with the FORWARDMAIL YES. We are supposed to receive (note - I meant "receive" instead of "accept", a subtle difference) no in-bound mail.
The default "FORWARDMAIL YES ENDFORWARDMAIL" has been commented out, not turned into an explicit NO. That appears to be a problem. I will pass that on to the people who do the definitions. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Alan Altmark > Sent: Thursday, October 05, 2006 11:02 PM > To: [email protected] > Subject: Re: Accesses Denied > > > On Thursday, 10/05/2006 at 08:38 MST, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > Thanks, Alan. That will help if something like this happens in the > future. I > > presume that there is no way to get the information from any logs > created in > > the past (Monday, to be exact). Too bad. The default seems > to be to log > only > > things that succeed. Alas, that is great for being able to > say, "As far > as I > > can tell, my system is working," but is no help in > troubleshooting or in > > > researching problems. > > No. What you see is what you get for SMTP logs; no history files are > maintained. If you wanted to use the VERIFYCLIENT exit to > send a message > to a logging server, that would be cool. You can record as > much or as > little data as you want. > > Oh, and silly me, I forgot to mention the FORWARDMAIL configuration > statement. If you don't want your VM system to be a relay host, set > FORWARDMAIL NO. In that case it will only accept mail that > originates > from or is destined for a user on the VM system itself. With > FORWARDMAIL > EXIT you can get more creative. Oh, sure, for users RICHARD > and CHUCKIE > it will happily do that, but not for anyone else. Unless > fave beverages > are left under the park bench, of course. > > But no worries, mate. Your network infrastructure did what it was > supposed to: it alerted someone that there is a problem. Too bad it > didn't keep one of the pieces of mail as a sample since the Received > headers would have revealed the IP address of the sender (back to the > point you quit trusting the relays). > > > I wish I had a way to know in advance when and what type of > problems we > are > > going to have so that I could turn the appropriate information > collectors on > > when they will be needed. TCPIP needs a Log What I Need > facility. :-) > Any > > chance that Chucky knows how to do that? > > He says it involves some experimental widget call the "Time Offset > Facility". This ... thing ..., so he says, includes an epoch > offset so > that it can run instructions at an arbitrary point in time in > the past. > This way, after you know you have a problem, you can turn on > the traces in > the past so that they are available now. Ow! Headache! (He > took a class > in temporal mechanics while at the Academy.) All I know is that the > machine room is littered with large magnets and something that looks > vaguely like, get this, Jacob's Ladder. And you know where > the cooling > lines enter the books? Well, when I look there I feel > somewhat queasy, as > though something is there but I can't *quite* see it. (I took a > flashlight. No help.) He just says "The TOF's existence must be > inferred, Grasshopper." Right. Whatever. Personally (don't > tell him I > told you this), I don't trust him. Shifty eyes. > > Alan Altmark > z/VM Development > IBM Endicott >
