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.
One of our postfix servers is for sending/receiving internal emails only. When a user entered a wrong recipient address, it will take almost an hour for the user to get the "Recipient address rejected" email. What can be done to let the user get the "Recipient address rejected" email quickier. Thanks.
I'm no expert, but you can't speed up the rejection rate of outgoing emails necessarily. The other server may accept any email address and only reject it hours later (or not at all).
If you would like it to reject emails destined for addresses that are supposed to exist on your server, you may find this useful.
We have two postfix servers and they are for internal use only (cannot send to/receieve from outside). We want users to receive the "Recipient address rejected" warning emails quickier. In fact, users connect to one of the postfix server can receive the "Recipient address rejected" warning emails right away, but users connect to the other postfix server can only receive the warning emails an hour later. Can it be a dns problem?
Mail servers can be complicated and there may be a spam blocker or virus scan stage before the mail even gets to the point where it's checked against your valid recipients list to be rejected or not.
I'm pretty new to this as well, but my guess is that you'll need to provide us with more information about your servers. Are you running spamassassin? clamav? amavisd? Looking at a bounced mail header might give some more insight.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
Have you checked the output of postconf -n from both servers and compared them? They might actually be configured differently and all you need to do is correct the bounce options to match.
Here is the output of the postconf of the postfix server which has problem. I have checked the other postfix server and the settings are pretty much the same.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
Pretty much != The same
The least error-prone way to check is this
Code:
server 1> postconf -n >/tmp/server1-main.conf
server 2> postconf -n >/tmp/server2-main.conf
server 2> scp server1:/tmp/server1-main.conf /tmp
server 2> diff /tmp/server1-main.conf /tmp/server2-main.conf
Also are the /etc/resolv.conf entries the same on both servers? What about /etc/hosts?
After adding back the right DNS record, the problem has been partially solved. Users can receive the warning email right away now when they typed in a non-existing user name. The remaining problem is when they enter a wrong domain name (the @xxxx.com part). They do not receive the "Relay access denied" email right away and do not know their emails are not sent out. How could this problem be solved? Thanks
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.