Well, unless something could be done with transport rules, I'm out of ideas.
Sorry. Kurt On Wed, Jul 22, 2015 at 12:24 PM, Tony Patton <[email protected]> wrote: > We've just finished the Exchange 2003 decomm couple of weeks ago, as part of > that we had to set up 2 IIS smtp relays to take over the work the old > front-ends did as they didn't want to have to configure all the applications > that were configured to use 7 different DNS names & 6 different IPs, along > with the associated Firewall configurations. 2 servers were required as > they need to be in separate VLANs. > > Setting up any new VMs is out, and we want anything new to be going directly > to the 2010 HT/CAS servers, rather than through additional servers. > > On 22 Jul 2015 19:48, "Kurt Buff" <[email protected]> wrote: >> >> On Wed, Jul 22, 2015 at 10:42 AM, Tony Patton <[email protected]> wrote: >> > That's what we have here, but the issue is that it then allows to send >> > to >> > any external email address, they want to restrict it to the internal >> > domain >> > and a *trusted* domain only. >> >> I get that, but my question would be "Is this app hardcoded to send >> only to this trusted domain, or can users specify the destination?" If >> the latter, well, I'd seek a way to mitigate that within the app. If >> the former, I wouldn't worry abut it. >> >> > Some systems have a legitimate need to be sending to all external >> > domains, >> > and we add the IPs of those to the allowed list. >> >> Yup. >> >> > We have another contract that is a subset of the parent organisation, >> > and >> > that domain is set as an internal relay, so if the mailbox isn't on that >> > exchange environment the mails get sent to the smart host. >> > >> > I'd sorry of hoped that the external relay domain would have worked for >> > the >> > issue on this contract, I.e. Relay all mail it receives on the receiver >> > connector from the apps servers straight to the smart host. >> >> I wonder if there's a way to use some Exchange scripting to handle >> that. I don't see a way to set a smarthost on a receive connector. It >> would be a nice feature, though. >> >> > That way only anything that has a legitimate need to email beyond those >> > 2 >> > domains needs to be added to the allowed list. >> > >> > I'll just tell them that it can't be done, and they need to get security >> > approval before getting added to the allowed list. Much simpler on my >> > side >> > :-) >> > >> > Tony >> >> Seems like your best bet, unless you want to set up another box with a >> hub transport role and put a smarthost on that for your purpose. Or, >> getting more exotic, set up a *nix box with Postfix to do the same >> thing. >> >> Actually, setting up a limited VM with just hub transport on it might >> be an interesting way of handling this... >> >> Kurt >> >> >> >> > On 22 Jul 2015 17:59, "Kurt Buff" <[email protected]> wrote: >> >> >> >> We have a similar situation here, also using Exchange 2010 - we have >> >> two classes of non-human email senders, those that send emails for >> >> internal use only and are allowed to send anonymously but only >> >> internally, and those that come from our CRM and go to external >> >> customers - we've allowed these to send anonymously also. >> >> >> >> The approach I took was to set up an extra IP address (with matching >> >> FQDN in DNS - I used "allowanonymousinternal.example.tld" and >> >> "allowanonymousexternal.example.tld") on the Exchange server for each >> >> of the two new connectors, then limit incoming to each connector to >> >> specific sending IP addresses. >> >> >> >> So far it's worked well for us. >> >> >> >> Kurt >> >> >> >> On Wed, Jul 22, 2015 at 7:27 AM, Tony Patton <[email protected]> wrote: >> >> > Hi folks, >> >> > >> >> > We have a requirement to try to restrict applications relaying via >> >> > Exchange >> >> > to the internal domain and another email domain, without opening it >> >> > up >> >> > to >> >> > allow emails to relay to any and all domains, unless the IP has been >> >> > added >> >> > to the allowed list. >> >> > >> >> > The internal Exchange domain is CompanyA.com, which routes all >> >> > external >> >> > emails to MimeSweeper filters, no Exchange Edge servers are >> >> > implemented. >> >> > >> >> > We do have smtp receive connectors set up for the applications to >> >> > relay >> >> > with >> >> > IP address restrictions, but is either an all or nothing as far as >> >> > external >> >> > email goes and Security aren't happy with that approach. The sending >> >> > servers/applications either can't or won't use Authentication, so all >> >> > connections to the receive connector is Anonymouns. >> >> > The Send connector is configured to route mail via the smart hosts by >> >> > IP, so >> >> > doesn't try to resolve the CompanyB.com MX record. >> >> > >> >> > Remote domains is the Default *, and a single Send Connector with >> >> > address * >> >> > pointing to the MimeSweeper servers. >> >> > >> >> > Can an Accepted Domain configured as "External Relay Domain" with the >> >> > CompanyB.com domain accomplish what we are being asked to do? I.e. >> >> > any >> >> > server not allowed by IP can then send to both domains, with the >> >> > emails >> >> > for >> >> > CompanyB sent to the MimeSweeper filters as normal? Or is there >> >> > another >> >> > "safe" way to do this? Or something I'm missing completely? >> >> > >> >> > Obviously we don't want to impact emails being sent by CompanyA users >> >> > to >> >> > CompanyB users. >> >> > >> >> > The servers are Exchange 2010 SP3 RU6, soon to be RU9, if that has a >> >> > bearing >> >> > on it. >> >> > >> >> > If it can't be done easily or safely, for various definitions of >> >> > both, >> >> > they >> >> > will just have to fight it out with the security team. >> >> > >> >> > I've looked at various TechNet & MSExchange.org articles, but >> >> > everything >> >> > I've come across assumes that Edge servers in place, so looking for >> >> > alternate confirmation on whether it will work or not. >> >> > >> >> > If I haven't explained it correctly, hit me with a big stick, I've >> >> > been >> >> > coming back to this over the course of the day so may be a bit >> >> > muddled >> >> > :) >> >> > >> >> > Thanks, >> >> > >> >> > Tony >> >> >> >> >> > >> >> >
