Как включить Relay на Exchange 2007 или 2010

Как обычно пишу сюда решения по достаточно актуальным вопросам, которые часто требуются, но приходится "покопать" просторы Инета, чтобы их обнаружить.
Краткая предистория... В моей организации развернут Exchange 2007, поскольку организация небольшая (не много пользователей почтового сервиса), то практически все роли на одном сервере, кроме Edge, конечно. Edge отдельный сервер в DMZ, как завещает нам всем MS.
ВНЕЗАПНО потребовалось сделать так, чтобы с определенных серверов можно было отправлять почту не только внутри организации, но и внешнему подрядчику... Сразу получил отлуп по Relay denied. Чуть погуглив нашел корректное описание того, как делается Relay для Exchange 2007, а заодно и 2010.
Привожу текст as is (учим английскую мову, оригинал всей статьи здесь):

Allow relaying: The easy way

With the new IP address added to the Exchange server – let’s say it is 192.168.1.17, and your app server, device or copier that needs to relay is 192.168.1.100, fire up Exchange shell and use the following command:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings ’192.168.1.17:25′ -fqdn server.domain.com -RemoteIPRanges 192.168.1.100 -server MYEXCHANGESERVER -permissiongroups ExchangeServers -AuthMechanism ‘TLS, ExternalAuthoritative’

What this does:

• Creates a new Receive Connector called RelayConnector
• Specifies the usage type Custom
• Binds the Receive Connector to port 25 on IP address 192.168.1.17
• Gives it the FQDN of server.domain.com
• Allows only the host with the IP address 192.168.1.100 to connect to it (specified by the RemoteIPRanges parameter)

Additionally, and most importantly, it assigns the ExchangeServers permission group to it, and disables authentication. When you select ExternalAuthoritative for authentication, you’re telling Exchange that you completely trust the IP address(es) or subnets specified in the RemoteIPRanges parameter (192.168.1.100) and you have another authentication mechanism outside of Exchange, such as IPSec, to authenticate.
This also bypasses all security for messages received from that IP address. Because Exchange treats all hosts specified in RemoteIPRanges as trusted, it doesn’t apply anti-spam filters, doesn’t enforce message size limits, resolves P2 headers, and allows sending on behalf of users. Going back to Exchange Server 2003, this is somewhat similar to adding the sending host’s address to Connection Filtering‘s Global Accept list.

A better, more secure way to allow relaying

If you want it to be more secure, you can create a Receive Connector with PermissionGroups set to AnonymousUsers:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings ’192.168.1.17:25′ -fqdn server.domain.com -RemoteIPRanges 192.168.1.100 -server MYEXCHANGESERVER -permissiongroups AnonymousUsers

Notice, we’ve left out the AuthMechanism parameter in the above command. However, we’re still restricting it to a particular IP address— 192.168.1.100. The big difference from the previous approach is we’re not treating the host as trusted.
Next, allow anonymous users to relay. This is done by allowing anonymous users the extended right ms-Exch-SMTP-Accept-Any-Recipient for this Connector:

Get-ReceiveConnector RelayConnector | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

Сделал оба варианта, проверил - работает! Если что-то не работает - пишем, будем разбираться почему.