Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a huge problem. A lot of messages went out from our mail server with the hostname of 192.168.0.3 instead of it's real hostname. How that happened is a different issues (that's not even that host's LAN IP).
This bad hostname got us blacklisted at Spamhaus. I fixed the servername and deleted the messages in /var/spool/mqueue. However, these messages keep popping up and trying to send with the bad hostname in the header. Where are they coming from? How do I kill them?
Did you bounce sendmail? Did you try stopping sendmail, deleting the mailq, then restarting? It may be these are in memory.
Did you check your maillog (/var/log) to see if it shows these being relayed from some other system that may still have them in queue? In our environment we have multiple servers that can send mail to our main out bound server to be relayed. Stopping mail on that outbound server wouldn't be sufficient to clean up any mail from the relaying servers that is still pending. We'd have to address the mail on those.
Have you verified your system isn't an open relay allowing others from outside your company to relay mail? Spammers love finding and exploiting such open relays.
Did you bounce sendmail? Did you try stopping sendmail, deleting the mailq, then restarting? It may be these are in memory.
Did not try restarting sendmail. Did that just now, but didn't help messages are still popping up in the mqueue.
Quote:
Did you check your maillog (/var/log) to see if it shows these being relayed from some other system that may still have them in queue? In our environment we have multiple servers that can send mail to our main out bound server to be relayed. Stopping mail on that outbound server wouldn't be sufficient to clean up any mail from the relaying servers that is still pending. We'd have to address the mail on those.
Most of these message were originated on a different server, but I did clear out that server's mqueue, restarted sendmail and have been watching mailq. Nothing there.
Quote:
Have you verified your system isn't an open relay allowing others from outside your company to relay mail? Spammers love finding and exploiting such open relays.
Yes, I have programs checking that. Besides, I recognize the email addresses as originating with us and being legit.
These are retried from when it failed earlier due to the blacklisting. Where does sendmail keep messages to retry if not in /var/spool/mqueue?
I had this same problem and found that there were 2 folders with queued messages. The folder /var/spool/clientmqueue/ had messages that were ending up in /var/spool/mqueue/ if they failed to be delivered. Deleting the files from both folders were necessary to solve the problem.
This comment especially:
I had this same problem and found that there were 2 folders with queued messages. The folder /var/spool/clientmqueue/ had messages that were ending up in /var/spool/mqueue/ if they failed to be delivered. Deleting the files from both folders were necessary to solve the problem.
I did initially delete the clientmqueue folder, but didn't keep checking it.
However, I think I found the source of these emails. It seems that the batch job on the other host restarted after rebooting. I don't quite understand why it restarted, but I'll not worry about that now. These new messages seem to be now going out with the correct hostname in the mail header and are not getting rejected. I'm going to let it go and not try to stop anything at this point. A few will get rejected because some of the recipient servers can take up to 24 hours to get the un-blacklist notice.
It remains a mystery why the mail server hostname got changed. Perhaps I fat-fingered something without realizing it.
I'll consider this solved and not spin my wheels trying to figure that out ... unless it happens again.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.