What happened aprox 10 days ago?

T

TestUser

Verified User
Joined
Aug 26, 2011
Messages
222
Aproximatelly 10 days ago some users on my server started to notice problems with sending emails wia web using php.
Its really strange problem, becouse its not same for all users...
in queued emails on www server for perticular user i see this constantly

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:

usersemail
all hosts for 'domain' have been failing for a long time (and retry time not reached)

how can i fix this?
spf is correct, everithing is like it should be but emails are not send using email server...
how can i debug and fix this?
 
TestUser said:
emails wia web using php
Click to expand...
So using php mail, so not authenticated via a php script.
And if I understand correctly, some users are able to send e-mails outgoing. Via both authenticated mail (smtp) and php?

Can be any kind of cause, you have to check the logfiles.
Especially the queue mails, mostly there is some info to be found there as to why they are not delivered.
Also the /home/user/.php/php-mail.log logfiles can shed a light on things.
 
This is in queue log for email that fails...
i have removed the domain name
2023-08-22 17:31:46 Received from <> R=1qYTMA-0002Nq-0k U=mail P=local S=1947 T="Mail delivery failed: returning message to sender"
2023-08-22 17:31:46 useremail F=<> R=lookuphost T=remote_smtp: all hosts for 'domain.com' have been failing for a long time (and retry time not reached)
*** Frozen (delivery error message)
 
You need to insure that domain is a fully registered domain name. And you need to insure that domain has a proper MX record set and if your server can connect to that server.

dig domain MX

will return the MX records for domain. If nothing is returned then the MTA is supposed to revert back to the domain's A record

dig domain A

Then taking that information, you will need to insure that your server is able to connect to that server via SMTP

telnet %whatever_dig_returned% 25

If this times out, then you probably have a block some where. Either your server is blocking outbound requests to this host or the host is blocking inbound requests from your server. One way to test this is to try connecting from another server.

If this telnet connection succeeds then clear out your Exim connection database caches:

rm -f /var/spool/exim/db/*

And the messages should be sent out.
 
Interesting... now i get this erro in queue
host mailserver [ip of mailserver]
SMTP error from remote mail server after HELO www.server:
550 Bad HELO - Host impersonating domain name [www.server]
ideas?

and yes i have added www.server domain to spf for this user....
 
TestUser said:
and yes i have added www.server domain to spf for this user....
Click to expand...
Seems you're making various mistakes. One does not add www.server to spf records.

Also:
TestUser said:
Received from <>
Click to expand...
Did you remove that or...?

Try giving some correct domain name or names which have issues so we can do a decent investigation of what's wrong.
If you don't want to do it public, do it via pm (can take more time, I'm very busy at the moment).
 
Yea, given your last post, I'm no longer sure if you're having trouble sending mail out from your server to someone else or if someone else is having trouble sending messages to you.

In either case it would appear that www.server - whatever that may be referring to - exists on both servers. Which is why the server being connected to is complaining about it being impersonating a local domain.

By default, the HELO that a DirectAdmin server uses when it sends out mail is going to be the primary hostname - what you see when you run the command hostname

This can be overwritten if /etc/virtual/helo_data exists with specific HELO data for a particular outbound IP address. I can't help you much with this because I don't use this feature.

On a DirectAdmin server if an incoming HELO matches a domain that is listed in /etc/virtual/domains then that server - the one handling the inbound SMTP traffic - will deny the connection with the error - Bad HELO - Host impersonating domain name.

So if the hostname of the DirectAdmin server sending out the message has a hostname of host.example.tld then it's probably using a HELO name of host.example.tld. If the recipient server - the server the message is being sent to is DirectAdmin server and it's hostname is also host.example.tld or otherwise has host.example.tld listed in /etc/virtual/domains then that recipient DirectAdmin server is going to reject the message with a Bad HELO - Host impersonating domain name message.

If the hostnames for both servers is the same, then that's probably the problem.

But that's all just a guess on my part.
 
I think problem is becouse i moved to new server dns records...but on old dns server old dns records still there... will test and let you all know
 
The most interesting thing is.... other users can.normaly do.this... just this ine user has problems
 
It's not the bind service what is causing the issue. As I explained it's exim, the mailserver, which isn't looking at bind but looking at /etc/virtual and domains in there.
Whitelist the ip's as I suggested and the problem should be gone.

Do the others send via php script plain, or authenticated? Can have various reasons.
 
It could also be another setting.
Check this users MX page and doublecheck that "use this server to handle email" is not selected!
 
If it is unselected on the old and selected on the good server then it's ok.
However. It's then odd that this is the only entry in the /etc/virtual directory. Something must have gone wrong, but not with this user but with the other users.

Users with domain -and- local mail should all have entry's in the /etc/virtual directory and in /etc/virtual/domainowners and the /etc/virtual/domains file.
Users with domain local but mail on any external server, normally have the same, but only do not exist in the /etc/virtual/domains file.
Check if the domain is in the /etc/virtual/domains file, if yes remove from there.

However, since you say none of the other domains has any entry in the /etc/virtual directory, it looks to me as something is wrong anyway.
I'm not sure if you just can remove that one domain from there without causing issues.
 
Thank you rickard,

adding server ips to this on both www and email server...
now all works as expected...
/etc/virtual/whitelist_hosts_ip

thank you!
 
You must log in or register to reply here.
Back
Top