This rule blocks a lot of legitimate e-mail.
Technically the rule and action are correct; there is an internal IP in the MX record.
However, this internal IP is our own mailserver!
A DNS fixup rule in the firewall translates the IP address. To the outside world the MX record is perfectly fine.
Both the Scrollout and the mailserver are on the same (internal) subnet in the DMZ, not having the IP address translated to an internal address would actually break e-mail delivery.
Is there a way to work around this issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe the CIDR notation is correct. The mailserver has IP address 10.10.20.109/23, while the F1 machine has 10.10.20.54/23.
The /23 is not an error. I have tried splitting the /23 into two /24 entries, just in case the wider /23 subnet is misread.
the strange thing is the trust networks (mynetworks in config files) precede the MX checks and should work.
Maybe the IP of the email server is behind a nat, in a DMZ or something in which case you need to look in logs and see the IP that connects on behalf of your email server.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having this same issue. I have 2 exchange (mail1, IP 170, exch64, IP 134) servers, mail for both is being filtered by scrollout. What I can't understand is I can send email from accounts on 170 to accounts on 134 without issue. When I try to send from an account on 134 to 170, scrollout rejects the message saying:
spam1.domain.com gave this error:
<exch64.mcsmail.local>: Helo command rejected: Internal IP in MX record or Helo command For assistance, see domain=.com or contact your administrator. Please provide the following information in your problem report: Time: (Sep 15 11:24:42), Client: (spamfilter's external IP), Server: (spam1.domain.com).
I tried adding the internal IP of exch64 to the inbound trust networks, and tried adding it to the whitelist, but to no affect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got that Error too, i have a scanner here which sends the scanned documents per eMail over Scrollout. The IP of the scanner is in the trusted inbound networks. But Scrollout always checks the Senderaddress in the AD. In the earlier versions it worked fine. When the IP from the senderdevice was in the trusted networks, then the Senderaddress was not checked in the AD. Scrollout is now checking and rejecting the eMails after last done update with:
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: connect from unknown[192.168.0.125]
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: NOQUEUE: reject: RCPT from unknown[192.168.0.125]: 550 5.1.0 kopierer@**.de: Sender address rejected: User unknown in relay recipient table; from=kopierer@.de to=ps@***.de proto=ESMTP helo=KMA74781
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: disconnect from unknown[192.168.0.125]
I think because there is no User associated with "kopierer@..." in the AD?! .. But when the eMail comes from an device of the trusted network it must not check the address of the Sender.
Anyone got an solution for that? :)
Greets,..
Last edit: Anonymous 2014-09-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What port are you using to send,messages to scrollout, 25 or 587?
The protection is good, reduces the forged senders, but I would like to find a way to allow trusted network.
Marius
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose I must be using port 25 (this is whatever send connector is created in Exchange 2010 when you create a send connector, I don't see anywhere in the send connector properties where you can specify an alternate port).
I was able to get my mail to start being delivered by specifying a different FQDN in the send connector properties (Both of my exchange servers had this setting blank, I added a FQDN to the one that wasn't working and it started working).
I assume that this made it start working because now the scrollout box is doing a DNS lookup on that FQDN, getting an external IP address, and being happy with that? I suppose this means that the server is now spam filtering the email that goes between these two exchange servers, which I suppose is not bad (perhaps unnecessary).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alternative port for Connector smarthost (in Exchange) can be set from command line (Windows shell):
Set-SendConnector Connector-Name -port 587
I don't know exactly why is working for you now, I can assume few things:
1) Sender is the same for sure, but the IP used to go out may appear different for Exchange now.
2) On the topic: I don't have a proper testing environment for this case, but I double-checked the settings and Trusted IPs and/or authenticated servers should be excluded from the Sender verification added few days ago.
I insist, please ensure the IP presented to Scrollout is the same as the one in Trust Networks which must input as CIDR: 192.168.1.1/32.
You can see what IP is presented in Monitor > Logs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My scanner is sending on Port 25. As i said it worked fine in the Release 2014-08-28, but since the Update to the latest version it blocks the Senderaddress although the IP from my scanner is in the trusted networks. :(
Luckily i had done a snapshot before i updated, so i could quickly return to the release 2014-08-28.
But why is the new version blocking Senderaddress that not exists in the AD from trusted devices?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The comment above applies here too - is an additional sender verification added 2-3 days ago which should not be applied when server authentication is used or the correct IP/32 is added in Trust Networks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, thanks for your answer.
The IP of my Scanner is in the trusted network with the correct IP.
(192.168.0.125/32), but Scrollout nevertheless blocks it.
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: NOQUEUE: reject: RCPT from unknown[192.168.0.125]: 550 5.1.0 kopierer@.de: Sender address rejected: User unknown in relay recipient table; from=kopierer@.de to=ps@*.de proto=ESMTP helo=KMA74781
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't have a solution other than creating that address in your AD.
Maybe I'll remove the sender validation setting for local domains, in the next update.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem seems to have returned. Probably my own fault from tuning the connection filter.
It would be great if the trusted networks actually had precedence over this rule.
Last edit: BOOZy 2015-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
This rule blocks a lot of legitimate e-mail.
Technically the rule and action are correct; there is an internal IP in the MX record.
However, this internal IP is our own mailserver!
A DNS fixup rule in the firewall translates the IP address. To the outside world the MX record is perfectly fine.
Both the Scrollout and the mailserver are on the same (internal) subnet in the DMZ, not having the IP address translated to an internal address would actually break e-mail delivery.
Is there a way to work around this issue?
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Try adding the IP in Inbound , trust networks as cidr.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
The whole subnet is there, so I gather the rule is ignoring this setting.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
then any message from that subnet (192.168.1.0/24) should be passed.
Please make sure is in CIDR format.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I believe the CIDR notation is correct. The mailserver has IP address 10.10.20.109/23, while the F1 machine has 10.10.20.54/23.
The /23 is not an error. I have tried splitting the /23 into two /24 entries, just in case the wider /23 subnet is misread.
Last edit: Anonymous 2014-09-09
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
please try 10.10.20.109/32 for the email server only
or
10.10.20.0/24 of the subnet.
First one is more secure while the second will allow any infected machine to send malware.
Unfortunately that didn't work either.
Btw, I'm the OP, forgot to login with the earlier posts.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
what is the release date? Look at the right-bottom corner.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Release 2014-08-13
the strange thing is the trust networks (mynetworks in config files) precede the MX checks and should work.
Maybe the IP of the email server is behind a nat, in a DMZ or something in which case you need to look in logs and see the IP that connects on behalf of your email server.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Had the same problem here when trying to get ScrolloutF1 to work inside the DMZ behind the firewall. Got it solved by adding the IP to the whitelist…
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I am having this same issue. I have 2 exchange (mail1, IP 170, exch64, IP 134) servers, mail for both is being filtered by scrollout. What I can't understand is I can send email from accounts on 170 to accounts on 134 without issue. When I try to send from an account on 134 to 170, scrollout rejects the message saying:
spam1.domain.com gave this error:
<exch64.mcsmail.local>: Helo command rejected: Internal IP in MX record or Helo command For assistance, see domain=.com or contact your administrator. Please provide the following information in your problem report: Time: (Sep 15 11:24:42), Client: (spamfilter's external IP), Server: (spam1.domain.com).
I tried adding the internal IP of exch64 to the inbound trust networks, and tried adding it to the whitelist, but to no affect.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Got that Error too, i have a scanner here which sends the scanned documents per eMail over Scrollout. The IP of the scanner is in the trusted inbound networks. But Scrollout always checks the Senderaddress in the AD. In the earlier versions it worked fine. When the IP from the senderdevice was in the trusted networks, then the Senderaddress was not checked in the AD. Scrollout is now checking and rejecting the eMails after last done update with:
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: connect from unknown[192.168.0.125]
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: NOQUEUE: reject: RCPT from unknown[192.168.0.125]: 550 5.1.0 kopierer@**.de: Sender address rejected: User unknown in relay recipient table; from=kopierer@.de to=ps@***.de proto=ESMTP helo=KMA74781
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: disconnect from unknown[192.168.0.125]
I think because there is no User associated with "kopierer@..." in the AD?! .. But when the eMail comes from an device of the trusted network it must not check the address of the Sender.
Anyone got an solution for that? :)
Greets,..
Last edit: Anonymous 2014-09-18
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
What port are you using to send,messages to scrollout, 25 or 587?
The protection is good, reduces the forged senders, but I would like to find a way to allow trusted network.
Marius
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I suppose I must be using port 25 (this is whatever send connector is created in Exchange 2010 when you create a send connector, I don't see anywhere in the send connector properties where you can specify an alternate port).
I was able to get my mail to start being delivered by specifying a different FQDN in the send connector properties (Both of my exchange servers had this setting blank, I added a FQDN to the one that wasn't working and it started working).
I assume that this made it start working because now the scrollout box is doing a DNS lookup on that FQDN, getting an external IP address, and being happy with that? I suppose this means that the server is now spam filtering the email that goes between these two exchange servers, which I suppose is not bad (perhaps unnecessary).
Alternative port for Connector smarthost (in Exchange) can be set from command line (Windows shell):
Set-SendConnector Connector-Name -port 587
I don't know exactly why is working for you now, I can assume few things:
1) Sender is the same for sure, but the IP used to go out may appear different for Exchange now.
2) On the topic: I don't have a proper testing environment for this case, but I double-checked the settings and Trusted IPs and/or authenticated servers should be excluded from the Sender verification added few days ago.
I insist, please ensure the IP presented to Scrollout is the same as the one in Trust Networks which must input as CIDR: 192.168.1.1/32.
You can see what IP is presented in Monitor > Logs.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
My scanner is sending on Port 25. As i said it worked fine in the Release 2014-08-28, but since the Update to the latest version it blocks the Senderaddress although the IP from my scanner is in the trusted networks. :(
Luckily i had done a snapshot before i updated, so i could quickly return to the release 2014-08-28.
But why is the new version blocking Senderaddress that not exists in the AD from trusted devices?
The comment above applies here too - is an additional sender verification added 2-3 days ago which should not be applied when server authentication is used or the correct IP/32 is added in Trust Networks.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi, thanks for your answer.
The IP of my Scanner is in the trusted network with the correct IP.
(192.168.0.125/32), but Scrollout nevertheless blocks it.
Sep 18 11:15:01 Spamfilter postfix/smtpd[21303]: NOQUEUE: reject: RCPT from unknown[192.168.0.125]: 550 5.1.0 kopierer@.de: Sender address rejected: User unknown in relay recipient table; from=kopierer@.de to=ps@*.de proto=ESMTP helo=KMA74781
I don't have a solution other than creating that address in your AD.
Maybe I'll remove the sender validation setting for local domains, in the next update.
The current release (2014-09-23) uses the aggressive sender verification on Connection levels 1-3.
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Does the 2014-09-23 build address the reported issue?
2014-09-24 excluded the reported verification for Connection level >=6.
I just posted the update a minute ago.
The problem seems to have returned. Probably my own fault from tuning the connection filter.
It would be great if the trusted networks actually had precedence over this rule.
Last edit: BOOZy 2015-08-25
View and moderate all "Get Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Port 587 is less restrictive for outbound, try it instead of 25.