If you are allowing them to act as an email client (via ActiveSync or OWA or whatever), their sending IP would be your Exchange server just like an Outlook MAPI client or OWA user would be I believe.
-----Original Message----- From: David W. McSpadden [mailto:dav...@imcu.com] Sent: Tuesday, March 30, 2010 10:28 AM To: MS-Exchange Admin Issues Subject: RE: Migrating SMTP email to Exchange 2003 Ok. I'll have to see that one in print to understand it a little better. So I have these people with Iphones that want to send and receive emails as well. If I spf the mx and ip they are still going to get refused or at the very least Be addressed as spammers because their ip will be that of the closest 3G tower?? Right? -----Original Message----- From: Don Andrews [mailto:don.andr...@safeway.com] Sent: Tuesday, March 30, 2010 1:25 PM To: MS-Exchange Admin Issues Subject: RE: Migrating SMTP email to Exchange 2003 I believe that if you use the "mx" option in your SPF record, it means to include the IPs from your MX records as valid senders. -----Original Message----- From: David W. McSpadden [mailto:dav...@imcu.com] Sent: Tuesday, March 30, 2010 7:18 AM To: MS-Exchange Admin Issues Subject: Re: Migrating SMTP email to Exchange 2003 Ben, Wondering what an 'MX' SPF directive might be?? -Add a spf record to the 206.18.123.215. Yup. There are other ways (like the "mx" SPF directive), but during a transition like this it's best to be explict. -------------------------------------------------- From: "Ben Scott" <mailvor...@gmail.com> Sent: Monday, March 29, 2010 5:27 PM To: "MS-Exchange Admin Issues" <exchangelist@lyris.sunbelt-software.com> Subject: Re: Migrating SMTP email to Exchange 2003 > On Mon, Mar 29, 2010 at 11:50 AM, David W. McSpadden <dav...@imcu.com> > wrote: >> I have been given the green light to research bringing all mail in >> house onto the Exchange 2003 server. > > And there was much rejoicing! > >> I have a Windows 2003 Active Directory domain. I have an ASA >> firewall and an Ironport for email. > > IronPort is a mail filtering appliance, right? What does it do > currently? What *can* it do? If it has the features and the load > capacity, I would recommend having all your incoming *and* outgoing > mail go through the IronPort. That helps you control and monitor mail > you send as well as receive. > >> -Globally change the smtp addresses for all users that already have >> external accounts in Exchange to match. > > If you're not already using your Exchange server for other mail, I > would suggest modifying the recipient policy such that it > automatically generates an appropriate SMTP address as the Primary > address. It generally doesn't hurt anything to have multiple systems > configured to generate mail with your "From" address. > >> -Add an mx record to point to an outward facing address such as >> 206.18.123.215 >> -Add a dns record for mail.imcu.com or pop.imcu.com and smtp.imcu.com? > > Close but not quite. MX records take domain names (like > <mail.example.com>) on their RHS (Right Hand Side), not IP addresses. > So generally, you could create DNS records along these lines: > > imcu.com. MX mail.imcu.com. > mail.imcu.com. A 206.18.123.215 > >> -Add a route through the firewall to the ironport and a relay to the >> exchange box. (incoming) > > Pretty much. In more detail, to receive mail *from* other systems: > > You want the firewall to allow traffic with destination port TCP/25 > to the IronPort. > > If your inside network NAT'ed? If so, you also need the firewall > configured to do > port-forwarding/NAT/PAT/one-to-one-static-NAT/whatever-your-vendor-cal > ls-it between the public address and the IronPort. > > The IronPort should be configured to accept mail addressed *to* your > domain(s), and to forward that mail to your Exchange server. You > generally cannot rely on DNS to tell your IronPort this, because DNS > will be telling your IronPort to deliver your mail to itself. > > You want your Exchange server configured to accept mail addressed > *to* your domain(s). That's done with recipient policies, mentioned > above. > >> -Add a smtp route from exchange to the ironport and relay to the >> internet. >> (outgoing) > > Again, that's the gist of it. In detail, to send mail *to* other > systems: > > You want the firewall configured to allow traffic with destination > port TCP/25 to any outside host, from either the IronPort or the > Exchange server. (I recommend both even if you decide to have > Exchange relay outgoing mail through the IronPort. If the IronPort > ever has trouble, you can reconfigure Exchange to bypass and send > direct.) > > You want the IronPort configured to relay mail from the Exchange > server to any outside system. If you have other hosts which send > mail, add them, too. > > You want the Exchange server configured to relay all outgoing mail > through the IronPort. This can be done just by designating the > IronPort as the "SMTP smart host". You don't *need* an SMTP connector > for this. If you create an SMTP connector (it won't hurt), then > configure it with a mail route to the IronPort, as you say. > > Eventually, you want most computers on your LAN to be denied if they > attempt to relay mail directly through the IronPort. That would > indicate they are bypassing Exchange, which most of the time will be a > rogue system set-up without IT department knowledge, or a computer > compromised by malware to be a spam zombie. > >> -Import all Outlook Express mail into Exchange and the delete all >> mail from the outlook express clients and remove the mailboxes from >> there. > > You may want to do the migration in stages. > > First, get the Exchange server configured to *send* mail. You can > test that yourself by creating test accounts, logging in to other > users' PCs, etc. Exchange won't know about any of the other mail > going on, but you can make sure it can send. > > Once you're sure that's working, migrate people from Outlook > Express/Win Mail/etc. to Outlook proper, but still configured to POP > mail from your current mail host. That changes the client software, > and the mail storage and sending, but keeps mail coming in the old > way. The advantage here is that you can back out an individual > client, or put the whole project on hold, without really disrupting > anything. Since this is the big change in user experience, that's a > good place to have flexibility. > > Once everybody is storing all their mail on Exchange, and sending via > Exchange, cut over the MX. Now mail delivery will be via Exchange > instead of POP, but otherwise, things will work about the same as > before. The POP clients will continue to POP, they just won't find > mail to POP. > > Once you're satisfied the MX cut-over worked, deactivate the POP > client on everybody's PC. Then cancel off-site mailbox hosting. > > It's more work and more time to do it in stages, but it gives you > more places to stop and catch your breath, or even to temporarily > abort and roll-back if needed. > >> -Add a spf record to the 206.18.123.215. > > Yup. There are other ways (like the "mx" SPF directive), but during > a transition like this it's best to be explict. > >> I know I am missing a lot and I need to verify that the mail that was >> going to the mailanyone and still be retrieved until we are sure all >> the mailboxes and distribution lists are working??? > > If you're not already hosting mail on the IronPort or Exchange, then > you can test your set-up just by sending mail directly to the IP > address you configured for this. > > If mail is already going through the IronPort, see if it can support > some kind of "virtual hosting" by IP address, and configure a new > "virtual host" for your new setup. > >> Sidenote my OWA stopped working a while back. Nobody used it but me >> but if we go to this I will need to have it up and running. Where do >> I look to find out why it has stopped. > > Start by checking services (IIS *and* Exchange), make sure they're > running. Then check Event Viewer. If needed, turn up diagnostic > logging for the server in Exchange. > > -- Ben > > >
