Daily Archives: September 12, 2005

Copying your SMTP relay list to another computer

Godfrey mailed me with an Exchange problem tht was causing him quite a bit of work

We have a large number of IP addresses in our SMTP “relay list”
It’s a real pain to have to enter them into each new exchange server.
There must be some way of copying them across – do you know a way ?

Nope – I didn’t – I had to ask arround.  Fortunately Simon came up with this neat little tool which allows you to programmatically set the relay IPs (and allow/deny IPs) for an SMTP VSI in an Exchange org.  It is a COM object with sample VBscript so you can tailor it to suit your requirements. 

You can use the SMTP Internet Protocol Restriction and Accept/Deny List Configuration to programmatically set or view Internet Protocol (IP) restrictions on an SMTP virtual server and to add or remove IP addresses from your global accept or deny lists.  Exchange 2003 provides connection and relay control for its Simple Mail Transfer Protocol (SMTP) virtual servers. Additionally, Exchange 2003 provides connection filtering that allows you to configure IP addresses from which you want to accept connections or from which you want to always deny connections. These settings are configured in global accept and deny lists in Connection Filtering. An administrator can use these controls to limit the computers that can connect to a virtual server or that can relay e-mail to outside the Exchange organization.  

I forgot to add that there’s a common misconception about the use of that feature – you don’t need to put the IP’s of all your other Exchange Servers in the relay list to secure things,  Exchange Servers don’t ‘relay’ to each other. Some people think that this is the way to be ‘secure’ by doing something like this. So you don’t have to that at all and you’re just using that field to allow non exchange servers to relay, as that’s what it’s there for.

It’s also a great idea to have a look at Part one of the Exchange Transport and Routing guide that has quite a few extra bits on SMTP and relays if you want some background information – especially on correctly configuring your SMTP Server for relays which is *really important* so I’ve reproduced some of it here…

Setting Relay Restrictions
Relaying is the ability to forward mail to domains other than your own.  More specifically, relaying occurs when an inbound connection to your SMTP server is used to send e-mail messages to external domains. By default, your Exchange server accepts mail submitted by internal or authenticated users and sends it to an external domain. If your server is open for relaying, or if relaying is unsecured on your server, unauthorized users can use your server to send unsolicited commercial e-mail (spam). Therefore, to secure your SMTP virtual server, it is crucial that you set relay restrictions.
It is important to understand the difference between authenticated relaying and anonymous or open relaying:
Authenticated relaying:
  Authenticated relaying allows your internal users to send mail to domains outside of your Exchange organization, but requires authentication before the mail is sent. By default, Exchange allows only authenticated relaying.
Anonymous relaying:   Anonymous relaying allows any user to connect to your Exchange server and use it to send mail outside your Exchange organization.

The following examples demonstrate how Exchange Server 2003 accepts and relays mail by using authenticated relaying: 
An anonymous user connects to the SMTP virtual server and attempts to deliver mail to an internal user in the Exchange organization. 
   In this situation, the SMTP virtual server accepts the message because it is destined for an internal domain and because the user exists in Active Directory.
An anonymous user connects to the SMTP virtual server and attempts to deliver mail to an external user in an external domain. 
   In this situation, the SMTP virtual server rejects the mail because it is destined for an external domain for which the Exchange server is not responsible. Because the user is not authenticated, the SMTP virtual server does not relay this mail outside of the Exchange organization.
A user connects to the SMTP virtual server using a Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) client (for example, Outlook Express), authenticates, and then attempts to send a message to a user in an external domain. 
   In this situation, the e-mail client connects directly to the SMTP virtual server and authenticates the user. Although the message is destined for a remote domain, the SMTP virtual server accepts and relays this mail because the user is authenticated.

By using the relay control features of Exchange Server 2003, you can prevent third parties from relaying mail through your server. Relay control allows you to specify a list of incoming remote IP address and subnet mask pairs that have permission to relay mail through your server. Exchange checks an incoming SMTP client’s IP address against the list of IP networks that are allowed to relay mail. If the client is not allowed to relay mail, only mail that is addressed to local recipients is allowed. You can also implement relay control by domain. However, this approach requires the implementation of reverse DNS resolution, which is controlled at the SMTP virtual server level.

Powerful Powerpoint points

Jesper, who seems to live on planes at the moment, has blogged about how to make your Powerpoint presentations much more effective.  As someone who presents and listens to preentations regularly, I know only too well on the torture of a bad set of slides (especially if you’re the one who has to deliver them as is….)

Well worth a look at… and don’t forget to pick up some extra tips on the Office web site too.

I don’t envy your travel schedule though Jesper – it’ll give you lots of time to perfect your slides though 🙂