Exim rejecting outside messages as if local

[pcgh]

I am fighting an issue with my cPanel Exim server in which some customers are unable to receive mail from certain senders. The sender receives an error message back as if they were trying to SMTP directly through my server which of course they are not. The message they receive says:

<[email protected]>:
[MY SERVER IP] does not like recipient.
Remote host said: 550-[CUSTOMERS PROVIDER] [CUSTOMERS IP]:55846 is
currently not permitted to
550-relay through this server. Perhaps you have not logged into the
pop/imap
550-server in the last 30 minutes or do not have SMTP Authentication
turned on
550 in your email client.
Giving up on [MY SERVER IP]

So far I have seen this on only one domain I host (more may have experienced but not reported it) and with mail coming from two different providers – one Comcast, the other a small ISP in New Mexico.

Any help would be greatly appreciated.

Tony

 

[deftech]

having same problem.

 

[Bruce]

I also have this problem. I thought I was going nuts but only happens to one domain and someone is sending from a comcast e-mail account.
Get the same error or reject message like above post.

 

[sparek-3]

Does customersdomain.com exist in /etc/localdomains and /etc/userdomains ?

 

[Bruce]

Yes, the recipients domain is in both files.
It gets better.
I just had a client from one server send an e-mail in horde and the other server said :

----- Forwarded message from [email protected] -----
Date: Tue, 29 Aug 2006 12:34:59 -0400
From: Mail Delivery System <[email protected] >
Reply-To: Mail Delivery System <[email protected] >
Subject: Mail delivery failed: returning message to sender
To: [email protected]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

[email protected]
SMTP error from remote mail server after RCPT
TO:<[email protected]>:
host receivingdomain.com[receivingIP]: 550- sending.server.com
[sending.server.comIP]:54210 is currently not permitted to
550-relay through this server. Perhaps you have not logged into
the pop/imap
550-server in the last 30 minutes or do not have SMTP
Authentication turned on
550 in your email client.

------ This is a copy of the message, including all the headers. ------

 

[pcgh]

It is interesting that both of us are having this issue and at least are both experiencing it with a Comcast user sending email in. As I say, I have also seen this with email coming from a small ISP in New Mexico (zianet.com). I have sent email from my own Comcast account to the server and have not had a problem so it isn't all Comcast users either.

Since more than one of us is having the issue, there must be something in common...

I did have ClamAV up and running and removed it and that didn't do anything. I do run APF firewall and Mod Security if that matters.

This is the craziest thing.

Tony

 

[Bruce]

The example I posted above was sent from one of my servers in AZ using horde to one of my servers in NJ. Why would the NJ server reject the e-mail because of relaying when it is not relaying ?

 

[sparek-3]

Try /scripts/mailperm and if that doesn't work /scripts/exim4 --force.

It really looks like exim is not reading the localdomains file. I don't know why this is the case.

When a connection comes into the server. At the RCPT TO stage, the server will check to see if that is a domain that is local on the server. If it is, then it will accept the mail. If not, then its assumed that you are attempting to relay through the server, and since you have not checked a valid POP account on the server from that IP, then you are not allowed to relay through the server. However, since the message is being sent to a domain that exists on that server, then it should be accepted. You said the domain existed in the /etc/localdomains on the server that you are sending to.

I really don't know. You might check both exim logs (sending and receiving server) as you attempt to send a message.

 

[pcgh]

Not much action on this thread but I am hoping someone has something for this issue... It is still occurring to me as well. I have tried everything mentioned above. Also deleted locadomain and ran /scripts/updateuserdomains which recreated it and that did nothing.

As I say, the issue continues... Please help!

Tony

 

[HostIt]

Have just been through this with a customer. I checked all the usual things before realising their email was never actually hitting the server. There was NO entry in exim_mainlog when I sent a test email, it just bounced straight back to sender with the "not permitted to relay" message.

Sure enough, the client hadn't re-delegated their domain to our server correctly. Instead of using our nameservers, they'd used their registrar's built-in system to "point" the domain. Because of the way they'd configured it, their email was being routed through to one of our nameserver IPs (on a completely different server).

The moral: If you're not seeing the mail via exim_mainlog - check the DNS situation

 

[KyleG]

I fixed this problem by manually adding the domain to /etc/localdomains.

Seems to of fixed the problem although I can keep this updated.

 

[angelina_holy]

1.add the domain to /etc/localdomains


2. You need to configure your mail client to authenticate to the SMTP server when sending mail. It should be the same username/password that you use to check your mail

3.Also, you can try a upcp --force too

 

[pcgh]

Hmmm. Unfortunately localdomains and userdomains, in my case, already have the domain names in there so that isn't it. I did totally rebuild the localdomains as mentioned before.

You need to configure your mail client to authenticate to the SMTP server when sending mail.

Again, the problem is not with a user on the server SENDING email. It is someone outside sending an email inside. It is odd because the error message indicates otherwise.

Still trying to find a solution...

Tony

 

[HostIt]

Hmmm. Unfortunately localdomains and userdomains, in my case, already have the domain names in there so that isn't it. I did totally rebuild the localdomains as mentioned before.



Again, the problem is not with a user on the server SENDING email. It is someone outside sending an email inside. It is odd because the error message indicates otherwise.

Still trying to find a solution...

Tony

And you have checked for the incoming emails in exim_mainlog? My bet is you won't find them in there, and that their DNS is set up wrong, as mentioned above...

 

[pcgh]

And you have checked for the incoming emails in exim_mainlog? My bet is you won't find them in there, and that their DNS is set up wrong, as mentioned above...

Yup, the same error message is recorded in exim_mainlog and exim_rejectlog. Just had one from a large school district that was sending an email into one of my customers and it was rejected.

Still searching for the solution...

 

[pcgh]

Well, I submitted a ticket and had cPanel take a look. They couldn't come up with anything. Grrrr.

Tony

 

[pcgh]

I FIXED MINE!

I tried everything I could think of and then on a whim I removed everything out of my exim.conf that had been manually added in the past - specifically the ACL section. With that removed, there were no more false "relay" messages!

So, I went back and recreated the ACL section from scratch (using http://www.webhostgear.com/175.html as a starting point). After that, things were back to normal.

I haven't touched exim.conf in a very, very long time so I figure a cPanel update might have messed things up. Anyway, hopefully this helps someone else.

Tony