Community Discussions and Support
simultaneous usage of Mercury C and S possible?

[quote user="Joerg"][quote user="Thomas R. Stephenson"]

Again not sure what this means.  If this is the MAIL FROM: address of the sending server can't you just change this to match a valid email address on your system? 

[/quote]

Here my summary again.

The managing card of the server is a DELL DRAC5 card. This card creates its own e-mail sender address ( DRAC5@[192.168.21.244] )when sending notification e-mails. This sender address is not adjustable. I'm only able to set an address of a recipient, a message text and a SMTP server IP address.

Now I have adjusted Mercury S to receive those "non-local" e-mails from the server. Mercury S hands over them to the Mercury Relay Client which tries to dispatch them to the ISP SMTP server. But this will be rejected  by the ISP because of non-registered domain ([192.168.21.244]). That's clear.

 Is it rejecting the From: address or the MAIL FROM: address?    

Now I'm searching for an opportunity to change the "non-local" address of the DRAC5 card to a already registered address (at the ISP) when processing in Mercury. May be I could solve it in the same way like the "translation" of e-mail addresses for our users. For example: My nmae is Joerg Mueller, my Pegasus login name is "jm". This normally causes to a sender address like jm@domain.com. But our registered ISP addresses read j.mueller@domain.com. Now I have created a synonym.mer file where all local user addresses will be translated to the official ISP addresses. This works properly.

Personally I change the MERCURY UDG via pconfig.exe from

 *Reply address format :  "~p" <~L~L~8@host.domain>

to

*Reply address format :  "~p" <~r>

and the users "Reply To:" address is used in place of the ~r.  This allows the users to have multiple identities with different From: addresses.

May be I could solve my DRAC5 problem in a similar manner?

Not really since this is a forward and it's going to be using the original From: address in the forwarding.   If you are not allowed to  change the it then you might have to send to a local address and then pull via IMAP4/POP3 from the outside world.  You might also talk to your ISP and explain the problem to them and ask them how to handle this.

One more thing.  Do you have a fixed IP address?  Does the ISP block port 25?  If the answers are Yes and NO then try using MercuryE and bypass the ISPs rules. 

regards

Joerg

[/quote]
[quote user=&quot;Joerg&quot;][quote user=&quot;Thomas R. Stephenson&quot;]&lt;blockquote&gt;&lt;p&gt;Again not sure what this means.&amp;nbsp; If this is the MAIL FROM: address of the sending server can&#039;t you just change this to match a valid email address on your system?&amp;nbsp; &lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;Here my summary again. &lt;/p&gt;&lt;p&gt;The managing card of the server is a DELL DRAC5 card. This card creates its own e-mail sender address ( DRAC5@[192.168.21.244] )when sending notification e-mails. This sender address is not adjustable. I&#039;m only able to set an address of a recipient, a message text and a SMTP server IP address.&lt;/p&gt;&lt;p&gt;Now I have adjusted Mercury S to receive those &quot;non-local&quot; e-mails from the server. Mercury S hands over them to the Mercury Relay Client which tries to dispatch them to the ISP SMTP server. But this will be rejected&amp;nbsp; by the ISP because of non-registered domain ([192.168.21.244]). That&#039;s clear.&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&amp;nbsp;Is it rejecting the From: address or the MAIL FROM: address? &amp;nbsp; &amp;nbsp; &lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;Now I&#039;m searching for an opportunity to change the &quot;non-local&quot; address of the DRAC5 card to a already registered address (at the ISP) when processing in Mercury. May be I could solve it in the same way like the &quot;translation&quot; of e-mail addresses for our users. For example: My nmae is Joerg Mueller, my Pegasus login name is &quot;jm&quot;. This normally causes to a sender address like jm@domain.com. But our registered ISP addresses read j.mueller@domain.com. Now I have created a synonym.mer file where all local user addresses will be translated to the official ISP addresses. This works properly.&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Personally I change the MERCURY UDG via pconfig.exe from&lt;/p&gt;&lt;p&gt;&amp;nbsp;*Reply address format :&amp;nbsp; &quot;~p&quot; &amp;lt;~L~L~8@host.domain&amp;gt;&lt;/p&gt;&lt;p&gt;to&lt;/p&gt;&lt;p&gt;*Reply address format :&amp;nbsp; &quot;~p&quot; &amp;lt;~r&amp;gt;&lt;/p&gt;&lt;p&gt;and the users &quot;Reply To:&quot; address is used in place of the ~r.&amp;nbsp; This allows the users to have multiple identities with different From: addresses. &lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;May be I could solve my DRAC5 problem in a similar manner?&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Not really since this is a forward and it&#039;s going to be using the original From: address in the forwarding. &amp;nbsp; If you are not allowed to&amp;nbsp; change the it then you might have to send to a local address and then pull via IMAP4/POP3 from the outside world.&amp;nbsp; You might also talk to your ISP and explain the problem to them and ask them how to handle this.&lt;/p&gt;&lt;p&gt;One more thing.&amp;nbsp; Do you have a fixed IP address?&amp;nbsp; Does the ISP block port 25?&amp;nbsp; If the answers are Yes and NO then try using MercuryE and bypass the ISPs rules.&amp;nbsp; &lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;&lt;/blockquote&gt;[/quote]

Dear all,

Presently we are using Pmail in connection with Mercury C (relay client) for sending e-mails to the internet. This works very well. Now we've got a new server which supervises itself. In case he discovers a malfunction (e.g. harddrive crash), he is able to send an e-mail to the administrator. Unfortunately our internet email provider does not support unauthorized email access, but the server is not able to send emails with username and password authentication. Is it possible to install Mercury S or Mercury E parallel to an existing Mercury C? Or could I use Mercury C also for forwarding unauthorized emails from local network by using an official account from our email internet provider?

regards

 

Joerg

&lt;p&gt;Dear all,&lt;/p&gt;&lt;p&gt;Presently we are using Pmail in connection with Mercury C (relay client) for sending e-mails to the internet. This works very well. Now we&#039;ve got a new server which supervises itself. In case he discovers a malfunction (e.g. harddrive crash), he is able to send an e-mail to the administrator. Unfortunately our internet email provider does not support unauthorized email access, but the server is not able to send emails with username and password authentication. Is it possible to install Mercury S or Mercury E parallel to an existing Mercury C? Or could I use Mercury C also for forwarding unauthorized emails from local network by using an official account from our email internet provider?&lt;/p&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

You should use MercuryC or MercuryE for sending out.

You use MercuryS for receiving, either from internal sources (mail clients, web-apps, backup engines, UPSs, etc), and/or external sources.

So, MercuryS happily coexists with either MercuryC or MercuryE.

&lt;P&gt;You should use MercuryC or MercuryE for sending out. &lt;/P&gt; &lt;P&gt;You use MercuryS for receiving, either from internal sources (mail clients, web-apps, backup engines, UPSs, etc), and/or external sources.&lt;/P&gt; &lt;P&gt;So, MercuryS happily coexists with either MercuryC or MercuryE.&lt;/P&gt;

Or could I use Mercury C also for forwarding unauthorized emails from

local network by using an official account from our email internet

provider?

Not real sure where the problem lies.  Mercury/32 v4.62 MercuryC can perform a ESMTP authorization using a specified username and password so I'm not at all sure why the message is being rejected.  Is the ISP rejecting on the SMTP MAIL FROM: address?  You might want to turn on session logging in MercuryC and then send a message from this server to see exactly what is happening.

 

&lt;blockquote&gt;Or could I use Mercury C also for forwarding unauthorized emails from local network by using an official account from our email internet provider?&lt;/blockquote&gt;&lt;p&gt;Not real sure where the problem lies.&amp;nbsp; Mercury/32 v4.62 MercuryC can perform a ESMTP authorization using a specified username and password so I&#039;m not at all sure why the message is being rejected.&amp;nbsp; Is the ISP rejecting on the SMTP MAIL FROM: address?&amp;nbsp; You might want to turn on session logging in MercuryC and then send a message from this server to see exactly what is happening.&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

The way I understood it was that the supervising function in the new server can't handle SMTP AUTH, so the message has to be sent through Mercury instead, requiring MercuryS to receive it and using (already working) MercuryC for sending it.

/Rolf 

&lt;p&gt;The way I understood it was that the supervising function in the new server can&#039;t handle SMTP AUTH, so the message has to be sent through Mercury instead, requiring MercuryS to receive it and using (already working) MercuryC for sending it. &lt;/p&gt;&lt;p&gt;/Rolf&amp;nbsp;&lt;/p&gt;

[quote user="Rolf Lindby"]

The way I understood it was that the supervising function in the new server can't handle SMTP AUTH, so the message has to be sent through Mercury instead, requiring MercuryS to receive it and using (already working) MercuryC for sending it.

/Rolf 

[/quote]

 

Good Morning,

Sorry for my unsufficient description. But Rolf has successfully discovered my problem.

The new server is unable to send emails by AUTH SMTP. But AUTH SMTP is required by our ISP for all e-mail traffic. Because we already use Mercury/32 v4.52 on another server I could send the administrator notification e-mails also via Mercury and not directly to the internet. Presently Mercury C is active for forwarding all user e-mails from Pmail to the internet. Could I use Mercury C also for the admin notification e-mails? The notification settings at the new server contain only the destination e-mail address and a SMTP server IP address. Nothing more. Which Mercury Module could handle (forward) such e-mails? May be there is no need to activate another Mercury module when Mercury C is able to receive and forward not only our Pmail traffic (Pmail is working in local mode with a pmgate.sys) but also such ordinary e-mails.

best regards

Joerg

[quote user=&quot;Rolf Lindby&quot;]&lt;p&gt;The way I understood it was that the supervising function in the new server can&#039;t handle SMTP AUTH, so the message has to be sent through Mercury instead, requiring MercuryS to receive it and using (already working) MercuryC for sending it. &lt;/p&gt;&lt;p&gt;/Rolf&amp;nbsp;&lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Good Morning,&lt;/p&gt;&lt;p&gt;Sorry for my unsufficient description. But Rolf has successfully discovered my problem.&lt;/p&gt;&lt;p&gt;The new server is unable to send emails by AUTH SMTP. But AUTH SMTP is required by our ISP for all e-mail traffic. Because we already use Mercury/32 v4.52 on another server I could send the administrator notification e-mails also via Mercury and not directly to the internet. Presently Mercury C is active for forwarding all user e-mails from Pmail to the internet. Could I use Mercury C also for the admin notification e-mails? The notification settings at the new server contain only the destination e-mail address and a SMTP server IP address. Nothing more. Which Mercury Module could handle (forward) such e-mails? May be there is no need to activate another Mercury module when Mercury C is able to receive and forward not only our Pmail traffic (Pmail is working in local mode with a pmgate.sys) but also such ordinary e-mails.&lt;/p&gt;&lt;p&gt;best regards&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

Could I use Mercury C also for the admin notification e-mails?

Yes but since the server cannot do SMTP AUTH you are going to have to allow that servers IP address to relay off your server.   You'll have to setup an "allow" setting for this IP address under the MercuryS connection control since mail from this server is going to be sent off server.  This can be a problem if the other server is an SMTP host and the spammers find it. 

Personally though I would have it send to a specific address on your Mercury/32 server so relaying is not required and then setup a FORWARD file for that user to send the mail to the real destination.  This would keep the spammers from relaying to any other address off yuor Mercury/32 host.  

This assumes that the sending host is providing real SMTP addresses in the MAIL FROM and RCPT TO addresses.  If there is only an IP address in the MAIL FROM it should be bracketed, i.e. postmaster@[192.168.1.2].

&lt;blockquote&gt;Could I use Mercury C also for the admin notification e-mails?&lt;/blockquote&gt;&lt;p&gt;Yes but since the server cannot do SMTP AUTH you are going to have to allow that servers IP address to relay off your server. &amp;nbsp; You&#039;ll have to setup an &quot;allow&quot; setting for this IP address under the MercuryS connection control since mail from this server is going to be sent off server.&amp;nbsp; This can be a problem if the other server is an SMTP host and the spammers find it.&amp;nbsp; &lt;/p&gt;&lt;p&gt;Personally though I would have it send to a specific address on your Mercury/32 server so relaying is not required and then setup a FORWARD file for that user to send the mail to the real destination.&amp;nbsp; This would keep the spammers from relaying to any other address off yuor Mercury/32 host. &amp;nbsp; &lt;/p&gt;&lt;p&gt;This assumes that the sending host is providing real SMTP addresses in the MAIL FROM and RCPT TO addresses.&amp;nbsp; If there is only an IP address in the MAIL FROM it should be bracketed, i.e. postmaster@[192.168.1.2]. &lt;/p&gt;

Hi Thomas,

Our LAN is behind a NAT router and additionally secured by a firewall. That's why the likelihood of an abuse by spammers is very small.

I conclude from your comment that I additionally have to  activate Mercury S first for taking e-mails from other LAN stations than Pmail. Mercury S will hand over these e-mails to Mercury C for sending them to the internet. Is this right?

regards

Joerg

&lt;p&gt;Hi Thomas,&lt;/p&gt;&lt;p&gt;Our LAN is behind a NAT router and additionally secured by a firewall. That&#039;s why the likelihood of an abuse by spammers is very small.&lt;/p&gt;&lt;p&gt;I conclude from your comment that I additionally have to&amp;nbsp; activate Mercury S first for taking e-mails from other LAN stations than Pmail. Mercury S will hand over these e-mails to Mercury C for sending them to the internet. Is this right?&lt;/p&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

Yes, you will need to activate MercS. It is the SMTP server module that listens for incoming connections.

It will receive the mail from the new machine (or any other smtp client like pmail, thunderbird, outlook etc.) and pass it to the Mercury core for processing.

If the RCPT TO address is local it will be delivered to the local mailbox.

If it is non-local it will be passed to the MercC client module for forwarding to your external smarthost.

With no access from outside you can leave the anti-relaying controls unchecked (as long as you can trust your LAN users & machines [:)]).

 

&lt;p&gt;Yes, you will need to activate MercS. It is the SMTP &lt;b&gt;server&lt;/b&gt; module that listens for incoming connections.&lt;/p&gt;&lt;p&gt;It will receive the mail from the new machine (or any other smtp client like pmail, thunderbird, outlook etc.) and pass it to the Mercury core for processing.&lt;/p&gt;&lt;p&gt;If the RCPT TO address is local it will be delivered to the local mailbox.&lt;/p&gt;&lt;p&gt;If it is non-local it will be passed to the MercC client module for forwarding to your external smarthost.&lt;/p&gt;&lt;p&gt;With no access from outside you can leave the anti-relaying controls unchecked (as long as you can trust your LAN users &amp;amp; machines [:)]).&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[quote user="Joerg"]

Hi Thomas,

Our LAN is behind a NAT router and additionally secured by a firewall. That's why the likelihood of an abuse by spammers is very small.

My system is also behind a firewall and NAT router but that has no affect if the mail received by the system is being forwarded via another system who treats my SMTP host as a trusted relay host.  ;-( 

I conclude from your comment that I additionally have to  activate Mercury S first for taking e-mails from other LAN stations than Pmail. Mercury S will hand over these e-mails to Mercury C for sending them to the internet. Is this right?

Correct, the system would be sending to MercuryS and Mercury core would forward it on to the outside world via you current MercuryC setup.  Again, I really recommend you send from the first system to only one local address on the Mercury/32 system that is forwarded to a single off server address.  This way you do not have to allow the first system to relay off the Mercury/32 system

regards

Joerg

[/quote]
[quote user=&quot;Joerg&quot;]&lt;blockquote&gt;&lt;p&gt;Hi Thomas,&lt;/p&gt;&lt;p&gt;Our LAN is behind a NAT router and additionally secured by a firewall. That&#039;s why the likelihood of an abuse by spammers is very small.&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;My system is also behind a firewall and NAT router but that has no affect if the mail received by the system is being forwarded via another system who treats my SMTP host as a trusted relay host.&amp;nbsp; ;-(&amp;nbsp; &lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;I conclude from your comment that I additionally have to&amp;nbsp; activate Mercury S first for taking e-mails from other LAN stations than Pmail. Mercury S will hand over these e-mails to Mercury C for sending them to the internet. Is this right?&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Correct, the system would be sending to MercuryS and Mercury core would forward it on to the outside world via you current MercuryC setup.&amp;nbsp; Again, I really recommend you send from the first system to only one local address on the Mercury/32 system that is forwarded to a single off server address.&amp;nbsp; This way you do not have to allow the first system to relay off the Mercury/32 system &lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;&lt;/blockquote&gt;[/quote]

[quote user="Thomas R. Stephenson"]

My system is also behind a firewall and NAT router but that has no affect if the mail received by the system is being forwarded via another system who treats my SMTP host as a trusted relay host.  ;-( 

[/quote]

How should it work? We have denied any incomming traffic by the firewall rules. Only reply packets to user requests (http, ftp, https), or VPN packets can pass the firewall. All other traffic will be blocked. Also all incoming e-mails will be pulled by POP3 requests from Mercury and will not be delivered via Port 25 SMTP. Please tell me, what I have overseen.

 greetings 

Joerg

[quote user=&quot;Thomas R. Stephenson&quot;] &lt;p&gt;My system is also behind a firewall and NAT router but that has no affect if the mail received by the system is being forwarded via another system who treats my SMTP host as a trusted relay host.&amp;nbsp; ;-(&amp;nbsp; &lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;How should it work? We have denied any incomming traffic by the firewall rules. Only reply packets to user requests (http, ftp, https), or VPN packets can pass the firewall. All other traffic will be blocked. Also all incoming e-mails will be pulled by POP3 requests from Mercury and will not be delivered via Port 25 SMTP. Please tell me, what I have overseen. &lt;/p&gt;&lt;p&gt;&amp;nbsp;greetings&amp;nbsp;&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

With your firewall setup, that won't allow incoming SMTP traffic at all, there will not be any problem with unwanted relaying.

/Rolf 

&lt;p&gt;With your firewall setup, that won&#039;t allow incoming SMTP traffic at all, there will not be any problem with unwanted relaying.&lt;/p&gt;&lt;p&gt;/Rolf&amp;nbsp;&lt;/p&gt;

Now I have activated the Mercury S module and it receives e-mails from the server management card after some try and error adjustments. The e-mails are handed over to the relay module which forwards them to the ISP SMTP server. But this one refuse those e-mails because of an unknown domain name.

Basically all local Pmail user have their own user names for local Pmail login which differ from their final official e-mail addresses. That's why we have created a synonym.mer file containing all users which changes the user name to the right e-mail address. Finally the Mercury relay client is connecting to the ISP AUTH SMTP server by using only one ISP user login and sends all e-mails (from different users) in a row.

Also the e-mails from the management card of the new server will be sent via this official ISP account login but in the format  DRAC5@[192.168.21.246]. This has been rejected from the ISP by "DNS lookup failed". Should I create another synonym entry for the DRAC5 management card now or is there another solution available?

regards

Joerg

&lt;p&gt;Now I have activated the Mercury S module and it receives e-mails from the server management card after some try and error adjustments. The e-mails are handed over to the relay module which forwards them to the ISP SMTP server. But this one refuse those e-mails because of an unknown domain name.&lt;/p&gt;&lt;p&gt;Basically all local Pmail user have their own user names for local Pmail login which differ from their final official e-mail addresses. That&#039;s why we have created a synonym.mer file containing all users which changes the user name to the right e-mail address. Finally the Mercury relay client is connecting to the ISP AUTH SMTP server by using only one ISP user login and sends all e-mails (from different users) in a row. &lt;/p&gt;&lt;p&gt;Also the e-mails from the management card of the new server will be sent via this official ISP account login but in the format&amp;nbsp; DRAC5@[192.168.21.246]. This has been rejected from the ISP by &quot;DNS lookup failed&quot;. Should I create another synonym entry for the DRAC5 management card now or is there another solution available?&lt;/p&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

Also the e-mails from the management card of the new server will be

sent via this official ISP account login but in the format 

DRAC5@[192.168.21.246]. This has been rejected from the ISP by "DNS

lookup failed". Should I create another synonym entry for the DRAC5

management card now or is there another solution available?

I'd tell it to use a local address matching one of your valid local user.
&lt;blockquote&gt;Also the e-mails from the management card of the new server will be sent via this official ISP account login but in the format&amp;nbsp; DRAC5@[192.168.21.246]. This has been rejected from the ISP by &quot;DNS lookup failed&quot;. Should I create another synonym entry for the DRAC5 management card now or is there another solution available?&lt;/blockquote&gt;I&#039;d tell it to use a local address matching one of your valid local user.

[quote user="Thomas R. Stephenson"]

I'd tell it to use a local address matching one of your valid local user.
[/quote]

Hi Thomas,

 How could I "translate" the non-local address <DRAC5@[192.168.21.244]> to a local address which will be accepted by the ISP? I have already added an Alias in that way: DRAC5@[192.168.21.244] > user@ourdomain.com. But the relay process shows always the DRAC5 sender address which is not registered at the ISP.

Or should I add an additional "user" to the synonym.mer file, where all of our local users will be translated to the official ISP registered addresses?

regards

 

Joerg

&lt;p&gt;[quote user=&quot;Thomas R. Stephenson&quot;]&lt;/p&gt;&lt;p&gt;I&#039;d tell it to use a local address matching one of your valid local user. [/quote]&lt;/p&gt;&lt;p&gt;Hi Thomas,&lt;/p&gt;&lt;p&gt;&amp;nbsp;How could I &quot;translate&quot; the non-local address &amp;lt;DRAC5@[192.168.21.244]&amp;gt; to a local address which will be accepted by the ISP? I have already added an Alias in that way: DRAC5@[192.168.21.244] &amp;gt; user@ourdomain.com. But the relay process shows always the DRAC5 sender address which is not registered at the ISP.&lt;/p&gt;&lt;p&gt;Or should I add an additional &quot;user&quot; to the synonym.mer file, where all of our local users will be translated to the official ISP registered addresses?&lt;/p&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

 How could I "translate" the non-local address

<DRAC5@[192.168.21.244]> to a local address which will be

accepted by the ISP? I have already added an Alias in that way:

DRAC5@[192.168.21.244] > user@ourdomain.com. But the relay process

shows always the DRAC5 sender address which is not registered at the

ISP.

Again not sure what this means.  If this is the MAIL FROM: address of the sending server can't you just change this to match a valid email address on your system? 

 

&lt;blockquote&gt;&amp;nbsp;How could I &quot;translate&quot; the non-local address &amp;lt;DRAC5@[192.168.21.244]&amp;gt; to a local address which will be accepted by the ISP? I have already added an Alias in that way: DRAC5@[192.168.21.244] &amp;gt; user@ourdomain.com. But the relay process shows always the DRAC5 sender address which is not registered at the ISP.&lt;/blockquote&gt;&lt;p&gt;Again not sure what this means.&amp;nbsp; If this is the MAIL FROM: address of the sending server can&#039;t you just change this to match a valid email address on your system?&amp;nbsp; &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[quote user="Thomas R. Stephenson"]

Again not sure what this means.  If this is the MAIL FROM: address of the sending server can't you just change this to match a valid email address on your system? 

[/quote]

Here my summary again.

The managing card of the server is a DELL DRAC5 card. This card creates its own e-mail sender address ( DRAC5@[192.168.21.244] )when sending notification e-mails. This sender address is not adjustable. I'm only able to set an address of a receipient, a message text and a SMTP server IP address.

Now I have adjusted Mercury S to receive those "non-local" e-mails from the server. Mercury S hands over them to the Mercury Relay Client which tries to dispatch them to the ISP SMTP server. But this will be rejected  by the ISP because of non-registered domain ([192.168.21.244]). That's clear.

Now I'm searching for an opportunity to change the "non-local" address of the DRAC5 card to a already registered address (at the ISP) when processing in Mercury. May be I could solve it in the same way like the "translation" of e-mail addresses for our users. For example: My nmae is Joerg Mueller, my Pegasus login name is "jm". This normally causes to a sender address like jm@domain.com. But our registered ISP addresses read j.mueller@domain.com. Now I have created a synonym.mer file where all local user addresses will be translated to the official ISP addresses. This works properly.

May be I could solve my DRAC5 problem in a similar manner?

regards

Joerg

 

[quote user=&quot;Thomas R. Stephenson&quot;]&lt;p&gt;Again not sure what this means.&amp;nbsp; If this is the MAIL FROM: address of the sending server can&#039;t you just change this to match a valid email address on your system?&amp;nbsp; &lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;Here my summary again. &lt;/p&gt;&lt;p&gt;The managing card of the server is a DELL DRAC5 card. This card creates its own e-mail sender address ( DRAC5@[192.168.21.244] )when sending notification e-mails. This sender address is not adjustable. I&#039;m only able to set an address of a receipient, a message text and a SMTP server IP address.&lt;/p&gt;&lt;p&gt;Now I have adjusted Mercury S to receive those &quot;non-local&quot; e-mails from the server. Mercury S hands over them to the Mercury Relay Client which tries to dispatch them to the ISP SMTP server. But this will be rejected&amp;nbsp; by the ISP because of non-registered domain ([192.168.21.244]). That&#039;s clear. &lt;/p&gt;&lt;p&gt;Now I&#039;m searching for an opportunity to change the &quot;non-local&quot; address of the DRAC5 card to a already registered address (at the ISP) when processing in Mercury. May be I could solve it in the same way like the &quot;translation&quot; of e-mail addresses for our users. For example: My nmae is Joerg Mueller, my Pegasus login name is &quot;jm&quot;. This normally causes to a sender address like jm@domain.com. But our registered ISP addresses read j.mueller@domain.com. Now I have created a synonym.mer file where all local user addresses will be translated to the official ISP addresses. This works properly.&lt;/p&gt;&lt;p&gt;May be I could solve my DRAC5 problem in a similar manner?&lt;/p&gt;&lt;p&gt;regards&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;&lt;p&gt;&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