emails from mailman rejected with error "reject=550 Relaying denied. IP name possibly forged"
![](https://secure.gravatar.com/avatar/4bfa3880a0e4f37a4fad63519c6a9673.jpg?s=120&d=mm&r=g)
Hi,
I seem to have an issue with my mailhost server randomly rejecting emails from my mailman server whenever they are directed externally. My current setup is I have a mailman server running mailman and sendmail which sends all emails to my mailhost server also running sendmail. Mailhost passes the emails through mailscanner etc. and then relays them either externally or internally based on the target email. Internal relaying works just fine but external relaying seems to sporadically accept some addresses for delivery and reject others. the choice of addresses it chooses to accept or reject is different for every attempt I am so for example for my first attempt it will forward the email to the first and 3rd external email addresses and reject to forward to the rest and on the 2nd attempt it rejects the the 2nd and 3rd and 4th but sends the emails to the 1st and 5th addresses just fine and so on. My mailman server's logs do not show any errors but my mailhost does. this is the extract in question from my mailhost server mail log file: Jul 24 09:08:52 mailhost sm-mta[3296]: s6O88pSr003296: from=<Source-email@external-domain.com>, size=2260, class=0, nrcpts=1, msgid=<cq0nx1du5icvm2eubfc8lvdy.1406189339980@email.android.com>, proto=ESMTP, daemon=MTA-v4, relay=mail-we0-f174.external-domain.com [74.125.82.174]Jul 24 09:08:52 mailhost sm-mta[3296]: s6O88pSr003296: to=<mailman-list@dmz.on.internal-domain.com>, delay=00:00:00, mailer=esmtp, pri=32260, stat=queuedJul 24 09:08:53 mailhost MailScanner[2909]: New Batch: Scanning 1 messages, 2837 bytesJul 24 09:08:53 mailhost MailScanner[2909]: Virus and Content Scanning: StartingJul 24 09:09:07 mailhost MailScanner[2909]: MCP Checks: StartingJul 24 09:09:07 mailhost MailScanner[2909]: Uninfected: Delivered 1 messagesJul 24 09:09:07 mailhost MailScanner[2909]: Deleted 1 messages from processing-databaseJul 24 09:09:08 mailhost sendmail[3307]: s6O88pSr003296: to=<mailman-list@dmz.on.internal-domain.com>, delay=00:00:16, xdelay=00:00:01, mailer=esmtp, pri=122260, relay=mailman-server.dmz.on.internal-domain.com. [172.16.0.143], dsn=2.0.0, stat=Sent (s6O893Rm003831 Message accepted for delivery)Jul 24 09:09:16 mailhost sm-mta[3309]: s6O89FAL003309: ruleset=check_rcpt, arg1=<target-address@external.domain2.com>, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged), reject=550 5.7.1 <target-address@external.domain2.com>... Relaying denied. IP name possibly forged [mailhost ip address]Jul 24 09:09:16 mailhost sm-mta[3309]: s6O89FAL003309: from=<mailman-list-bounces@dmz.on.internal-domain.com>, size=4645, class=0, nrcpts=0, proto=ESMTP, daemon=MTA-v4, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged)Jul 24 09:09:16 mailhost sm-mta[3309]: s6O89FAN003309: <mailman-list-bounces@dmz.on.internal-domain.com>... User unknownJul 24 09:09:16 mailhost sm-mta[3309]: s6O89FAN003309: from=<>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA-v4, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged)Jul 24 09:09:16 mailhost sm-mta[3309]: s6O89FAP003309: from=<>, size=2657, class=0, nrcpts=1, msgid=<201407240809.s6O89CZP003837@mailman-server.dmz.on.internal-domain.com>, proto=ESMTP, daemon=MTA-v4, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged)Jul 24 09:09:16 mailhost sm-mta[3309]: s6O89FAP003309: to=<support-email@internal-domain.com>, delay=00:00:00, mailer=esmtp, pri=32657, stat=queuedJul 24 09:09:16 mailhost sm-mta[3310]: s6O89FRV003310: from=<mailman-list-bounces@dmz.on.internal-domain.com>, size=4640, class=-30, nrcpts=2, msgid=<cq0nx1du5icvm2eubfc8lvdy.1406189339980@email.android.com>, proto=ESMTP, daemon=MTA-v4, relay=mailhost.serscis.eu [mailhost ip address]Jul 24 09:09:16 mailhost sm-mta[3310]: s6O89FRV003310: to=<Source-email@external-domain.com>, delay=00:00:00, mailer=esmtp, pri=118640, stat=queuedJul 24 09:09:16 mailhost sm-mta[3310]: s6O89FRV003310: to=<target-address@external.domain.com>, delay=00:00:00, mailer=esmtp, pri=118640, stat=queuedJul 24 09:09:16 mailhost sm-mta[3311]: s6O89Fll003311: ruleset=check_rcpt, arg1=<target-address@external.domain3.com>, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged), reject=550 5.7.1 <target-address@external.domain3.com>... Relaying denied. IP name possibly forged [mailhost ip address]Jul 24 09:09:16 mailhost sm-mta[3311]: s6O89Fll003311: from=<mailman-list-bounces@dmz.on.internal-domain.com>, size=4640, class=-30, nrcpts=1, msgid=<cq0nx1du5icvm2eubfc8lvdy.1406189339980@email.android.com>, proto=ESMTP, daemon=MTA-v4, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged)Jul 24 09:09:16 mailhost sm-mta[3311]: s6O89Fll003311: to=<target-address@internal-domain.com>, delay=00:00:00, mailer=esmtp, pri=88640, stat=queuedJul 24 09:09:17 mailhost sm-mta[3311]: s6O89Fln003311: <mailman-list-bounces@dmz.on.internal-domain.com>... User unknownJul 24 09:09:17 mailhost sm-mta[3311]: s6O89Fln003311: from=<>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA-v4, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged)Jul 24 09:09:17 mailhost sm-mta[3311]: s6O89Flp003311: from=<>, size=2657, class=0, nrcpts=1, msgid=<201407240809.s6O89CZP003841@mailman-server.dmz.on.internal-domain.com>, proto=ESMTP, daemon=MTA-v4, relay=mailhost.server.in-dmz.on.internal-domain.com [mailhost ip address] (may be forged)Jul 24 09:09:17 mailhost sm-mta[3311]: s6O89Flp003311: to=<support-email@internal-domain.com>, delay=00:00:00, mailer=esmtp, pri=32657, stat=queued
Any help would be appreciated. ThanksAbZ
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Abdullah Maskari writes:
Looks to me like your DNS is quite broken (the references to IP addresses being forged). Many destination hosts will filter such mail.
The enhanced status code is 5.7.1, an administrative reject. You've violated somebody's spam-filtering policy, and they're not accepting mail from you. You might want to check if your IP address(es) are on a blackhole list.
However, I think the immediate priority is fixing your DNS so that your external mail server is the MX for your domain, which has a proper A and/or AAAA address (ie, the domain name advertised is not a CNAME), and has PTR record from the MX name to the server's IP.
![](https://secure.gravatar.com/avatar/4bfa3880a0e4f37a4fad63519c6a9673.jpg?s=120&d=mm&r=g)
Hi,
thanks for your reply.
I should have probably mentioned that I have another instance of mailman running on another server on the network and it is not having any trouble sending mail through mailhost. The sendmail files I am using for my mailman installation have been copied from the other server as the whole idea is to migrate from the currently working server to the one I built.
I will look at the spam filter configurations and my DNS but I dont see how any of those systems could be broken if the original mailman server is working fine.
Thanks Abdullah On 27/07/2014 00:54, Stephen J. Turnbull wrote:
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Abdullah AL-Maskari wrote:
Because different recipient servers respond differently to wrongly configured DNS, it might just be coincidence that the other list isn't having the same trouble. It might also be that it is having the same trouble, but with far less recipients.
Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Abdullah AL-Maskari writes:
It's not a question of whether something is broken; something is. The fact that your own logs record that your mailhost "may be forged" proves that. The questions are what it is, and whether this breakage is causing you problems.[1] If you have another Mailman host that works, you can check for differences in their configurations (including the list memberships!), as well as any aspects of the mailhost configuration that might treat them differently. But I still think it would be a good idea to configure your mailhost so that in the DNS it looks like a responsible citizen rather than a 'bot sending spam.
It occurs to me that the DNS problem may be that your HELO hostname (in the SMTP transaction) doesn't match the reverse lookup for the IP observed in the TCP connection. That should be easy to fix in the Sendmail configuration.
As for spam filters, it's probably not your spam filters that are rejecting your mail, it's filters on the recipient hosts. It's hard to tell from the log, though.
Footnotes: [1] You'll have to figure those out for yourself because you've redacted all useful information about your network. That's entirely up to you, of course, and it's more secure. But if you insist on security, you're going to have to take our wild guesses seriously.
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
That sounds like something similar to what happened to us when someone decided they'd reconfigure our mail server to send from a different ip address than we receive mail on.
We got away with it for a long time, but as more recipients installed spam filters (this was a few years ago), we began to see more bounces when we sent mail. Fixed by setting up reverse lookup for the sending address.
Peter Shute
![](https://secure.gravatar.com/avatar/4bfa3880a0e4f37a4fad63519c6a9673.jpg?s=120&d=mm&r=g)
So it seems that my problem is that my mailman server attempts to communicate with mailhost through mailhost's outward facing IP rather than through its internal network IP, I have added an entry for mailhost in the hosts file but sendmail still insists on communicating with mailhost through mailhost's external IP. I am not sure how to change this behaviour.
Abdullah
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Abdullah Maskari writes:
Aha! I'll have to remember that, I wouldn't be surprised if it comes up again.
I have added an entry for mailhost in the hosts file
This is generally not recommended. Most systems nowadays are configured to use the nameservers whenever possible, and only fall back to hosts when no nameserver can be contacted. Although you can change that priority (if you have write access to the appropriate configuration, often /etc/host.conf), this isn't recommended either as hosts is often untouched for years and easily becomes out of date and inaccurate.
First let me say this is way out of scope for this list.
That said, I can think of a couple of ways of addressing the situation.
My first suggestion is that you give the outgoing (*internal* IP) and incoming (*external* IP) SMTP gateways different names even if they're implemented on the same host. Then when your site expands enough to need a more powerful host, or separate hosts to service incoming and outgoing traffic, you just add the new host, change the DNS, and all your internal mail goes to the right place, ditto external mail, and nobody cares how your mail system works, it Just Works.
Second, you probably want internal hosts to be unable to see the external gateway and vice versa, so you may want to run two name servers, one (outside) which only knows about your hosts that provide public services (like web and mailservers, and is configured to return their external addresses), and one (inside) which knows about your internal network, but doesn't know about your public hosts (at least, not their public IP addresses and names), and recurses to your ISP's nameserver (*not* your "outside" nameserver!) for "remote" sites.
If the first suggestion is impossible for some reason, you could reconfigure to give the hosts file precedence. (The suggestion about two nameservers is optional if you're careful enough about firewalls, and don't care if names and internal network details leak.)
You should also look at your working list server and see how its configuration differs from this one. If you used the hosts file dodge on that one, then probably it is configured to give hosts precedence over DNS. My suggestion is to separate the DNS entries for outgoing and incoming and to change that one too.
Steve
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Abdullah Maskari writes:
Looks to me like your DNS is quite broken (the references to IP addresses being forged). Many destination hosts will filter such mail.
The enhanced status code is 5.7.1, an administrative reject. You've violated somebody's spam-filtering policy, and they're not accepting mail from you. You might want to check if your IP address(es) are on a blackhole list.
However, I think the immediate priority is fixing your DNS so that your external mail server is the MX for your domain, which has a proper A and/or AAAA address (ie, the domain name advertised is not a CNAME), and has PTR record from the MX name to the server's IP.
![](https://secure.gravatar.com/avatar/4bfa3880a0e4f37a4fad63519c6a9673.jpg?s=120&d=mm&r=g)
Hi,
thanks for your reply.
I should have probably mentioned that I have another instance of mailman running on another server on the network and it is not having any trouble sending mail through mailhost. The sendmail files I am using for my mailman installation have been copied from the other server as the whole idea is to migrate from the currently working server to the one I built.
I will look at the spam filter configurations and my DNS but I dont see how any of those systems could be broken if the original mailman server is working fine.
Thanks Abdullah On 27/07/2014 00:54, Stephen J. Turnbull wrote:
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Abdullah AL-Maskari wrote:
Because different recipient servers respond differently to wrongly configured DNS, it might just be coincidence that the other list isn't having the same trouble. It might also be that it is having the same trouble, but with far less recipients.
Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Abdullah AL-Maskari writes:
It's not a question of whether something is broken; something is. The fact that your own logs record that your mailhost "may be forged" proves that. The questions are what it is, and whether this breakage is causing you problems.[1] If you have another Mailman host that works, you can check for differences in their configurations (including the list memberships!), as well as any aspects of the mailhost configuration that might treat them differently. But I still think it would be a good idea to configure your mailhost so that in the DNS it looks like a responsible citizen rather than a 'bot sending spam.
It occurs to me that the DNS problem may be that your HELO hostname (in the SMTP transaction) doesn't match the reverse lookup for the IP observed in the TCP connection. That should be easy to fix in the Sendmail configuration.
As for spam filters, it's probably not your spam filters that are rejecting your mail, it's filters on the recipient hosts. It's hard to tell from the log, though.
Footnotes: [1] You'll have to figure those out for yourself because you've redacted all useful information about your network. That's entirely up to you, of course, and it's more secure. But if you insist on security, you're going to have to take our wild guesses seriously.
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
That sounds like something similar to what happened to us when someone decided they'd reconfigure our mail server to send from a different ip address than we receive mail on.
We got away with it for a long time, but as more recipients installed spam filters (this was a few years ago), we began to see more bounces when we sent mail. Fixed by setting up reverse lookup for the sending address.
Peter Shute
![](https://secure.gravatar.com/avatar/4bfa3880a0e4f37a4fad63519c6a9673.jpg?s=120&d=mm&r=g)
So it seems that my problem is that my mailman server attempts to communicate with mailhost through mailhost's outward facing IP rather than through its internal network IP, I have added an entry for mailhost in the hosts file but sendmail still insists on communicating with mailhost through mailhost's external IP. I am not sure how to change this behaviour.
Abdullah
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Abdullah Maskari writes:
Aha! I'll have to remember that, I wouldn't be surprised if it comes up again.
I have added an entry for mailhost in the hosts file
This is generally not recommended. Most systems nowadays are configured to use the nameservers whenever possible, and only fall back to hosts when no nameserver can be contacted. Although you can change that priority (if you have write access to the appropriate configuration, often /etc/host.conf), this isn't recommended either as hosts is often untouched for years and easily becomes out of date and inaccurate.
First let me say this is way out of scope for this list.
That said, I can think of a couple of ways of addressing the situation.
My first suggestion is that you give the outgoing (*internal* IP) and incoming (*external* IP) SMTP gateways different names even if they're implemented on the same host. Then when your site expands enough to need a more powerful host, or separate hosts to service incoming and outgoing traffic, you just add the new host, change the DNS, and all your internal mail goes to the right place, ditto external mail, and nobody cares how your mail system works, it Just Works.
Second, you probably want internal hosts to be unable to see the external gateway and vice versa, so you may want to run two name servers, one (outside) which only knows about your hosts that provide public services (like web and mailservers, and is configured to return their external addresses), and one (inside) which knows about your internal network, but doesn't know about your public hosts (at least, not their public IP addresses and names), and recurses to your ISP's nameserver (*not* your "outside" nameserver!) for "remote" sites.
If the first suggestion is impossible for some reason, you could reconfigure to give the hosts file precedence. (The suggestion about two nameservers is optional if you're careful enough about firewalls, and don't care if names and internal network details leak.)
You should also look at your working list server and see how its configuration differs from this one. If you used the hosts file dodge on that one, then probably it is configured to give hosts precedence over DNS. My suggestion is to separate the DNS entries for outgoing and incoming and to change that one too.
Steve
participants (4)
-
Abdullah AL-Maskari
-
Abdullah Maskari
-
Peter Shute
-
Stephen J. Turnbull