Re: "where" is the box?

Post #252,780 by inthane-chan 4/20/06 12:43:04 PM Reply	Re: "where" is the box? Box is right next to my desk at work, routing-wise it's inside the server room on the same IP subnet. I'm probably going to have to be the real source, as there are no exposed SMTP servers internal to our network at all. Box is not currently exposed to The Real World^TM - but will be eventually, in theory. This is actually just the "demo box" - a VMWare instance that will eventually be The Real Thing. Oh, and we're running Debian stable on the box currently. When somebody asks you to trade your freedoms for security, it isn't your* security they're talking about.*
Post #252,783 by broomberg 4/20/06 1:17:26 PM Reply	You are facing a open hallway There are many doors to your right. There is a twisty path to your left. You are carrying: Server Operating system Choice of MTAs Changing network Changing DNS environment Changing destination email packages with varying levels of authentication requirements. Firewalls. And lots of other baggage. You need to realize the email is a coopoerative endeavor between your system and the system it needs to talk to. So if you are not using a smarthost to hand the email off, so need to make sure your system name and DNS is setup. But if you are behind a firewall, then it is unlikely you have a public facing system, which in turn means you need to deal with address mapping and port level redirection. This quickly escalates into a brain siezure for people doing it the 1st time. And even if you get it to work, it might only be with SOME systems you are talking to, which means troubleshooting is really painful. So, I think you need allocate the final IP / DNS entries before you go to your next step since that drives much of the configuration.
Post #252,785 by inthane-chan 4/20/06 1:28:36 PM Reply	Ugh. For now, there is only one mailserver that the system needs to talk to - our own internal Exchange server. In fact, I may keep it that way in the long run, as the only people who will get notifications will be instructors. As this is a "beta" project, I just want something quick 'n dirty to hold together until I know what the heck I'm doing. When somebody asks you to trade your freedoms for security, it isn't your* security they're talking about.*
Post #252,787 by broomberg 4/20/06 1:32:12 PM Reply	Why can't you use the Exchange box as a forwarder? If so, setup is really easy.
Post #252,861 by inthane-chan 4/21/06 10:27:14 AM Reply	There might be the heady wiff of politics. No details, but suffice to say getting changes in firewall policy on our end is nigh impossible, and a problem as well on the other side. OTOH, if somebody can point me to an easy "accept mail only from localhost, and forward to single destination" script, I'll try that. When somebody asks you to trade your freedoms for security, it isn't your* security they're talking about.*
Post #253,178 by static 4/23/06 11:46:53 PM Reply	For Courier. Courier by default only accepts mail from localhost, so no configuration needed there - look in /etc/courier/smptaccess if you're curious. To make it send all mail on to one host for forwarding, put the following line into /etc/courier/esmtproutes: :[target IP] man courier has more information about /etc/courier/esmtproutes. Wade. "Insert crowbar. Apply force."
Post #252,835 by static 4/20/06 9:51:47 PM Reply	Barry's mostly right. First of all, many MTAs provide a sendmail binary for sending mail. So it doesn't have to be actual SendMail. Secondly, if the machine can contact a working Internet-aware DNS and has a default route out through your firewall - i.e. you could browse the 'net from it - then most any MTA can be dropped in and it will automatically find the right host and delivery mail a-okay. There might be a wrinkle if SMTP outbound is not permitted. In that case, you should drop your Exchange admins a line and ask about letting it forward SMTP for you. Then you don't need a working DNS, either. Wade. "Insert crowbar. Apply force."

Welcome to IWETHEY!