Community Discussions and Support
Relay only specified domains?

It's just a zip file with mxredir.txt & mxredir.dll

EDIT: Oops, that was my zip file, it's just the .dll available here (http://www.xs4all.nl/~fenke/files/mxredir.dll). The text file was a post from the mailing list. (copied below)

 

It seems fairly basic / beta but I tested it on 4.01b and it worked as advertised. Have not tried it on 4.5x but it should work.

Note the cautions about dropping undeliverable mail, I would suggest an 'Archive' filtering rule for that domain mail for backup purposes in case the network (or more likely Exchange [:P]) goes down.

 

 BEGIN MXREDIR.TXT

Have you thought of using a MX type operation here using a daemon?
Mercury/32  does not yet have the capability of forwarding all mail for a domain
off to another server.  That said, Frans Meijer has written a small daemon that
can do this.  I've tested this and it seems to work just fine.  You might want to
setup a Mercury/32 "Always" filter to send all of the mail for this domain off to
one of your local mail accounts so you'll not lose mail.

---------------------------------- quote ------------------------------------------------
A first version - for testing, not production use - is at

http://www.xs4all.nl/~fenke/files/


The actual daemon to use is mxredir.dll the rest are the sources to build it, for
which you also need daemon.h from the Mercury distribution and Borlands free
C++ compiler (should not be hard to port to other compilers though - mind the
alignment issues). 

Put the dll in a convenient directory, for instance the Mercury directory, assume
C:\Mercury for the remaining text and 192.168.2.3 is the ip address of the
receiving MTA. 

In Mercury Core config, local domains tab add a new domain. In the Edit
domain entry dialog fill in the local server and internet domain:

Local host or server: daemon:C:\Mercury\mxredir.dll;[192.168.2.3]
Internet name: test.local

(You can off course another domain name and ip address)

Messages send to <any-mailbox@test.local> should now be processed by the
daemon, you can see this in the core-process window (Job ... from ... To:
daemon:C:\M ...etc...) 


The daemon writes to a log file 'redirector.log' in the Mercury
directory.


Caution.

Mercury expects the domain-daemon to handle the message, it hands the job
over, then discards the original. If, for whatever reason, the daemon can not
forward the message, it is lost. A backup mechanism should be added, for
instance writing the message to a file somewhere, or dropping in a user mailbox
(though if it can't create the forward message that might be a problem to). Your
input is welcome. 

I feel there should be some more validations, for instance on the parameter
passed, maybe on the rcpt addresses. Perhaps not use a logfile (another point of
failure) and certainly not abort if it can't be opened. More? 

The current daemon will likely not work if the _source_ is a domain-popbox, I
don't know (yet) how the rcpt to address will look in the job-info passed to the
daemon, the daemon expects <mailbox@domain> 

As said, this is not (yet) for production. If anyone gives it a test-run, let me know
how it works, problems and change requests. (post here or to reply-to or if that
fails: <frans.meijer@xs4all.nl>) 

------------------------ end quote ---------------------------------------------------

END MXREDIR.TXT 

&lt;p&gt;It&#039;s just a zip file with mxredir.txt &amp;amp; mxredir.dll&lt;/p&gt;&lt;p&gt;EDIT: Oops, that was my zip file, it&#039;s just the .dll available here (http://www.xs4all.nl/~fenke/files/mxredir.dll). The text file was a post from the mailing list. (copied below) &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;It seems fairly basic / beta but I tested it on 4.01b and it worked as advertised. Have not tried it on 4.5x but it should work. &lt;/p&gt;&lt;p&gt;Note the cautions about dropping undeliverable mail, I would suggest an &#039;Archive&#039; filtering rule for that domain mail for backup purposes in case the network (or more likely Exchange&amp;nbsp;[:P]) goes down. &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;BEGIN MXREDIR.TXT&lt;/p&gt;&lt;p&gt;Have you thought of using a MX type operation here using a daemon? Mercury/32&amp;nbsp; does not yet have the capability of forwarding all mail for a domain off to another server.&amp;nbsp; That said, Frans Meijer has written a small daemon that can do this.&amp;nbsp; I&#039;ve tested this and it seems to work just fine.&amp;nbsp; You might want to setup a Mercury/32 &quot;Always&quot; filter to send all of the mail for this domain off to one of your local mail accounts so you&#039;ll not lose mail. ---------------------------------- quote ------------------------------------------------ A first version - for testing, not production use - is at http://www.xs4all.nl/~fenke/files/ The actual daemon to use is mxredir.dll the rest are the sources to build it, for which you also need daemon.h from the Mercury distribution and Borlands free C++ compiler (should not be hard to port to other compilers though - mind the alignment issues).&amp;nbsp; Put the dll in a convenient directory, for instance the Mercury directory, assume C:\Mercury for the remaining text and 192.168.2.3 is the ip address of the receiving MTA.&amp;nbsp; In Mercury Core config, local domains tab add a new domain. In the Edit domain entry dialog fill in the local server and internet domain: Local host or server: daemon:C:\Mercury\mxredir.dll;[192.168.2.3] Internet name: test.local (You can off course another domain name and ip address) Messages send to &amp;lt;any-mailbox@test.local&amp;gt; should now be processed by the daemon, you can see this in the core-process window (Job ... from ... To: daemon:C:\M ...etc...)&amp;nbsp; The daemon writes to a log file &#039;redirector.log&#039; in the Mercury directory. Caution. Mercury expects the domain-daemon to handle the message, it hands the job over, then discards the original. If, for whatever reason, the daemon can not forward the message, it is lost. A backup mechanism should be added, for instance writing the message to a file somewhere, or dropping in a user mailbox (though if it can&#039;t create the forward message that might be a problem to). Your input is welcome.&amp;nbsp; I feel there should be some more validations, for instance on the parameter passed, maybe on the rcpt addresses. Perhaps not use a logfile (another point of failure) and certainly not abort if it can&#039;t be opened. More?&amp;nbsp; The current daemon will likely not work if the _source_ is a domain-popbox, I don&#039;t know (yet) how the rcpt to address will look in the job-info passed to the daemon, the daemon expects &amp;lt;mailbox@domain&amp;gt;&amp;nbsp; As said, this is not (yet) for production. If anyone gives it a test-run, let me know how it works, problems and change requests. (post here or to reply-to or if that fails: &amp;lt;frans.meijer@xs4all.nl&amp;gt;)&amp;nbsp; ------------------------ end quote ---------------------------------------------------&lt;/p&gt;&lt;p&gt;END MXREDIR.TXT&amp;nbsp;&lt;/p&gt;

Hi All.

Is it possible to configure Mercury so that while local users can send to anywhere, it will only relay mail for certain specified domains?

If it is possible, would such relayed mail be subject to the  anti-spam and anti-virus mechanisms?

 

Regards,

Richard 

 

&lt;p&gt;Hi All.&lt;/p&gt;&lt;p&gt;Is it possible to configure Mercury so that while local users can send to anywhere, it will only relay mail for certain specified domains?&lt;/p&gt;&lt;p&gt;If it is possible, would such relayed mail be subject to the&amp;nbsp; anti-spam and anti-virus mechanisms?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards,&lt;/p&gt;&lt;p&gt;Richard&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[quote user="rhayward"]

Hi All.

Is it possible to configure Mercury so that while local users can send to anywhere, it will only relay mail for certain specified domains?

If it is possible, would such relayed mail be subject to the  anti-spam and anti-virus mechanisms?

 

Regards,

Richard 

 

[/quote]

 

Not sure what you are asking. 

Allowing relaying for specified domains, is not possible.  The biggest reason is that if a spammer sent mail using the domain name it would be relayed.  You can allow relaying for specific connecting IP addresses.

 You might be talking about the MX function of relaying mail for a domain to another server and if so this one is on the list to be implemented but I do not know when.


 

 

[quote user=&quot;rhayward&quot;]&lt;p&gt;Hi All.&lt;/p&gt;&lt;p&gt;Is it possible to configure Mercury so that while local users can send to anywhere, it will only relay mail for certain specified domains?&lt;/p&gt;&lt;p&gt;If it is possible, would such relayed mail be subject to the&amp;nbsp; anti-spam and anti-virus mechanisms?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards,&lt;/p&gt;&lt;p&gt;Richard&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Not sure what you are asking.&amp;nbsp; &lt;/p&gt;&lt;p&gt;Allowing relaying for specified domains, is not possible.&amp;nbsp; The biggest reason is that if a spammer sent mail using the domain name it would be relayed.&amp;nbsp; You can allow relaying for specific connecting IP addresses.&lt;/p&gt;&lt;p&gt;&amp;nbsp;You might be talking about the MX function of relaying mail for a domain to another server and if so this one is on the list to be implemented but I do not know when.&lt;/p&gt;&lt;p&gt; &amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Thanks for your reply Thomas.

The situation I'm thinking of would be where there are 2 mailservers, one Mercury and one Exchange, both on a private address range behind NAT.

The SMTP service visible to the outside world, as far as incoming connections are concerned, is that of the Mercury host only , but both servers can initiate outbound connections. The Mercury server has DomainA configured as a local domain, the Exchange server has DomainB and DomainC. For hosts in the outside world,  MX records for all 3 domains point to the publically visible address of the Mercury server. So inbound mail for all 3 domains arrives at the Mercury server. If that mail is for DomainB or DomainC then Mercury relays it to the Exchange server, because I've arranged for the MX records for those 2 domains to be different when queried by Mercury to what the outside world sees. Requests to Mercury from the outside world to relay mail to any domain other than B or C are ignored.

The objective in this is take advantage of Mercurys anti-spam and anti-virus capabilitys for mail destined to the Exchange server. 

 Is this possible?

 

Regards

Richard 

&lt;p&gt;Thanks for your reply Thomas.&lt;/p&gt;&lt;p&gt;The situation I&#039;m thinking of would be where there are 2 mailservers, one Mercury and one Exchange, both on a private address range behind NAT.&lt;/p&gt;&lt;p&gt;The SMTP service visible to the outside world, as far as incoming connections are concerned, is that of the Mercury host only , but both servers can initiate outbound connections. The Mercury server has DomainA configured as a local domain, the Exchange server has DomainB and DomainC. For hosts in the outside world,&amp;nbsp; MX records for all 3 domains point to the publically visible address of the Mercury server. So inbound mail for all 3 domains arrives at the Mercury server. If that mail is for DomainB or DomainC then Mercury relays it to the Exchange server, because I&#039;ve arranged for the MX records for those 2 domains to be different when queried by Mercury to what the outside world sees. Requests to Mercury from the outside world to relay mail to any domain other than B or C are ignored. &lt;/p&gt;&lt;p&gt;The objective in this is take advantage of Mercurys anti-spam and anti-virus capabilitys for mail destined to the Exchange server.&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;Is this possible?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards&lt;/p&gt;&lt;p&gt;Richard&amp;nbsp;&lt;/p&gt;

[quote user="rhayward"]

Thanks for your reply Thomas.

The situation I'm thinking of would be where there are 2 mailservers, one Mercury and one Exchange, both on a private address range behind NAT.

The SMTP service visible to the outside world, as far as incoming connections are concerned, is that of the Mercury host only , but both servers can initiate outbound connections. The Mercury server has DomainA configured as a local domain, the Exchange server has DomainB and DomainC. For hosts in the outside world,  MX records for all 3 domains point to the publically visible address of the Mercury server. So inbound mail for all 3 domains arrives at the Mercury server. If that mail is for DomainB or DomainC then Mercury relays it to the Exchange server, because I've arranged for the MX records for those 2 domains to be different when queried by Mercury to what the outside world sees. Requests to Mercury from the outside world to relay mail to any domain other than B or C are ignored.

The objective in this is take advantage of MercuryS anti-spam and anti-virus capabilitys for mail destined to the Exchange server. 

 Is this possible?

 

Regards

Richard 

[/quote]

 

Possible and it can be done in a couple of ways.

 

1.   Setup a domain account for the second domain in Mercury/32 and then have the Exchange host pull the mail from the Mercury/32 account to deliver it to the Exchange users.  I know there is POP3 connector software (http://www.mapilab.com/exchange/pop3_connector) available for Exchange to do this.   I'm not all that sure it can used the X-Envelope-To: header added by Mercury/32 so that the RCPT TO: address can be used for the mail delivery.  This is the easiest and most hands off solution assuming you can afford the cost of the Exchange POP3 connector software.

2.   Alias all the users of the second domain to the Exchange host.  For example, if the Exchange host has it's own host name and IP address you can alias the users on the Exchange host using user@domain.com to user@exchange.com and Mercury/32 will reroute the mail to the Exchange host.  If it does not have a real domain name you can also use the user@[192.168.1.x] form to route it to the Exchange host, not all that sure though that it's all that easy to setup Exchange to use literal addressing.


 

[quote user=&quot;rhayward&quot;]&lt;p&gt;Thanks for your reply Thomas.&lt;/p&gt;&lt;p&gt;The situation I&#039;m thinking of would be where there are 2 mailservers, one Mercury and one Exchange, both on a private address range behind NAT.&lt;/p&gt;&lt;p&gt;The SMTP service visible to the outside world, as far as incoming connections are concerned, is that of the Mercury host only , but both servers can initiate outbound connections. The Mercury server has DomainA configured as a local domain, the Exchange server has DomainB and DomainC. For hosts in the outside world,&amp;nbsp; MX records for all 3 domains point to the publically visible address of the Mercury server. So inbound mail for all 3 domains arrives at the Mercury server. If that mail is for DomainB or DomainC then Mercury relays it to the Exchange server, because I&#039;ve arranged for the MX records for those 2 domains to be different when queried by Mercury to what the outside world sees. Requests to Mercury from the outside world to relay mail to any domain other than B or C are ignored. &lt;/p&gt;&lt;p&gt;The objective in this is take advantage of MercuryS anti-spam and anti-virus capabilitys for mail destined to the Exchange server.&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;Is this possible?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards&lt;/p&gt;&lt;p&gt;Richard&amp;nbsp;&lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Possible and it can be done in a couple of ways.&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;1.&amp;nbsp;&amp;nbsp; Setup a domain account for the second domain in Mercury/32 and then have the Exchange host pull the mail from the Mercury/32 account to deliver it to the Exchange users.&amp;nbsp; I know there is POP3 connector software (http://www.mapilab.com/exchange/pop3_connector) available for Exchange to do this. &amp;nbsp; I&#039;m not all that sure it can used the X-Envelope-To: header added by Mercury/32 so that the RCPT TO: address can be used for the mail delivery.&amp;nbsp; This is the easiest and most hands off solution assuming you can afford the cost of the Exchange POP3 connector software. &lt;/p&gt;&lt;p&gt;2.&amp;nbsp;&amp;nbsp; Alias all the users of the second domain to the Exchange host.&amp;nbsp; For example, if the Exchange host has it&#039;s own host name and IP address you can alias the users on the Exchange host using user@domain.com to user@exchange.com and Mercury/32 will reroute the mail to the Exchange host.&amp;nbsp; If it does not have a real domain name you can also use the user@[192.168.1.x] form to route it to the Exchange host, not all that sure though that it&#039;s all that easy to setup Exchange to use literal addressing. &lt;/p&gt;&lt;p&gt; &amp;nbsp;&lt;/p&gt;

Hi Thomas,

It seems to me that both these solutions would require me to have knowledge of the accounts on the Exchange server. This isn't really practical as those accounts are changing all the time and this would be impossible to maintain. Please correct me if I'm mistaken.

I wondered if I might configure Mercury to be an open relay, except that somehow there are rules that

1: prohibit all outbound mail to domains other than B and C.

2: make an exception to this for clients connecting from hosts within the local private address range.

This would mean that users with accounts in DomainA, hosted by the Mercury server, couldn't use their mail from off-site.

 
Alternatively, if rule 2 isn't possible, have Mercury host no Domain itself at all, and just rely on rule 1. 

Regards,

Richard 

&lt;p&gt;Hi Thomas,&lt;/p&gt;&lt;p&gt;It seems to me that both these solutions would require me to have knowledge of the accounts on the Exchange server. This isn&#039;t really practical as those accounts are changing all the time and this would be impossible to maintain. Please correct me if I&#039;m mistaken. &lt;/p&gt;&lt;p&gt;I wondered if I might configure Mercury to be an open relay, except that somehow there are rules that &lt;/p&gt;&lt;p&gt;1: prohibit all outbound mail to domains other than B and C. &lt;/p&gt;&lt;p&gt;2: make an exception to this for clients connecting from hosts within the local private address range.&lt;/p&gt;&lt;p&gt;This would mean that users with accounts in DomainA, hosted by the Mercury server, couldn&#039;t use their mail from off-site.&lt;/p&gt;&lt;p&gt;&amp;nbsp; Alternatively, if rule 2 isn&#039;t possible, have Mercury host no Domain itself at all, and just rely on rule 1.&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards,&lt;/p&gt;&lt;p&gt;Richard&amp;nbsp;&lt;/p&gt;

> Hi Thomas,
>
> It seems to me that both these solutions would require me to
> have knowledge of the accounts on the Exchange server. This
> isn't really practical as those accounts are changing all the
> time and this would be impossible to maintain. Please correct
> me if I'm mistaken.

No, the first option with the POP3 connector would only require you to create a "domain" account on the Mercury/32 system and the people running the Exchange host would setup the POP3 connector to download the mail for their users.

>
> I wondered if I might configure Mercury to be an open relay,
> except that somehow there are rules that
>
> 1: prohibit all outbound mail to domains other than B and C.

Use filter rules I guess to delete all outbound mail to everything but these domains.  Not sure how this will work since the "delete" or "move"" outgoing rules do not work all that well right now.
 
>
> 2:  make an exception to this for clients connecting from
>     hosts within the local private address range.

Can't be done.

>
> This would mean that users with accounts in DomainA, hosted
> by the Mercury server, couldn't use their mail from off-site.

Agreed, this might work but I can't see how you can in fact block all mail except to specific domains without setting up the possibly of a relay off the second server.
 
>
>  
> Alternatively, if rule 2 isn't possible, have Mercury host no Domain itself at all, and just rely on rule 1.
>
> Regards,
>
> Richard

&amp;gt; Hi Thomas, &amp;gt; &amp;gt; It seems to me that both these solutions would require me to &amp;gt; have knowledge of the accounts on the Exchange server. This &amp;gt; isn&#039;t really practical as those accounts are changing all the &amp;gt; time and this would be impossible to maintain. Please correct &amp;gt; me if I&#039;m mistaken. No, the first option with the POP3 connector would only require you to create a &quot;domain&quot; account on the Mercury/32 system and the people running the Exchange host would setup the POP3 connector to download the mail for their users. &amp;gt; &amp;gt; I wondered if I might configure Mercury to be an open relay, &amp;gt; except that somehow there are rules that &amp;gt; &amp;gt; 1: prohibit all outbound mail to domains other than B and C. Use filter rules I guess to delete all outbound mail to everything but these domains.&amp;nbsp; Not sure how this will work since the &quot;delete&quot; or &quot;move&quot;&quot; outgoing rules do not work all that well right now. &amp;nbsp; &amp;gt; &amp;gt; 2:&amp;nbsp; make an exception to this for clients connecting from &amp;gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; hosts within the local private address range. Can&#039;t be done. &amp;gt; &amp;gt; This would mean that users with accounts in DomainA, hosted &amp;gt; by the Mercury server, couldn&#039;t use their mail from off-site. Agreed, this might work but I can&#039;t see how you can in fact block all mail except to specific domains without setting up the possibly of a relay off the second server. &amp;nbsp; &amp;gt; &amp;gt; &amp;nbsp; &amp;gt; Alternatively, if rule 2 isn&#039;t possible, have Mercury host no Domain itself at all, and just rely on rule 1. &amp;gt; &amp;gt; Regards, &amp;gt; &amp;gt; Richard

Check out the mxredir daemon (http://www.xs4all.nl/~fenke/files/)

I think it does what you want.

 

&lt;p&gt;Check out the mxredir daemon (http://www.xs4all.nl/~fenke/files/)&lt;/p&gt;&lt;p&gt;I think it does what you want.&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[quote user="dilberts_left_nut"]

Check out the mxredir daemon (http://www.xs4all.nl/~fenke/files/)

I think it does what you want.

 

[/quote]

 

This looks interesting. I'll see if I can get it to work. The only documentation I can find, via Google, is a document mxredirect.txt. That mentions (I assume Mercury) v 3.31. Any idea if it will work with the current Mercury version?

 

Regards,

Richard 

[quote user=&quot;dilberts_left_nut&quot;]&lt;p&gt;Check out the mxredir daemon (http://www.xs4all.nl/~fenke/files/)&lt;/p&gt;&lt;p&gt;I think it does what you want.&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;This looks interesting. I&#039;ll see if I can get it to work. The only documentation I can find, via Google, is a document mxredirect.txt. That mentions (I assume Mercury) v 3.31. Any idea if it will work with the current Mercury version?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards,&lt;/p&gt;&lt;p&gt;Richard&amp;nbsp;&lt;/p&gt;
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft