SimonH
17th November 2008, 17:52
Hi there. I have hunted these forums already, trying to find a solution to this problem. Although I've found threads detailing similar problems, none seem to be like this one.
Essentially, we have a problem with *some* people emailing users on our server. For the most part, mail works flawlessly, and we don't have any problems, but occaisionally, we find that some people just cannot email users on our server, no matter how hard they try, they get a bounce message like this (email addresses and hostnames have been changed to generic value's);
----- The following addresses had permanent fatal errors -----
<user@domain.tld> (reason: 550 5.1.1 <user@ispconfig.hostname>: Recipient address rejected: User unknown in local recipient table) ----- Transcript of session follows ----- ... while talking to ispconfig.hostname.: >>> DATA <<< 550 5.1.1 <user@ispconfig.hostname>: Recipient address rejected: User unknown in local recipient table 550 5.1.1 <user@domain.tld>... User unknown <<< 554 5.5.1 Error: no valid recipients
The thing I find strangest about this, is that user@domain.tld (the proper users email address on the ispconfig server) seems to be getting converted to user@ispconfig.hostname. ie. the domain name part of the email address is being converted to the hostname of the ispconfig server. I'm not sure if this is relevant, but it seems strange to me.
If I try to test this by sending an email from my personal googlemail account to the same email address, the mail goes through fine, and I cannot replicate the issue the senders are having.
It happens with multiple unrelated accounts, and multiple unrelated domains on the server, with multiple unrelated users with different ISP's sending the emails. Some users never have the problem at all, other users seem to have it a lot. I really don't know where to start with this. Adding to the problem, it's quite difficult to troubleshoot with senders who aren't my customer, but some are cooperative occaisionally, even though I haven't got anywhere with this in the end. At one point when this happened, I deleted the affected site and associated users and domains (DNS records included) from the ISPConfig control panel, emptied the recycle bin, and recreated them. This seemed to fix the problem for a while (I didn't have any compaints from the user), but now it's resurfaced for at least one of these customers. Obviously continually deleting and readding them (forcing them to update their login details) isn't really a good solution, if in fact it does work.
Apologies if I've missed a thread on this, and please feel free to point me in the direction of it if one exists. I hope somebody can help with this, as I have no idea what to do. There isn't really anything useful in /var/log/mail.log only things like;
Nov 17 15:15:32 apollo postfix/local[12940]: 90E3F6204: to=<web48_admin@ispconfig.hostname>, orig_to=<user@domain.tld>, relay=local, delay=5.4, delays=0.15/0/0/5.3, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -f-)
I have tried to odd trick like "postmap /etc/postfix/virtusertable" to rebuild the user table, but it hasn't helped.
Many Thanks In Advance,
Simon
Essentially, we have a problem with *some* people emailing users on our server. For the most part, mail works flawlessly, and we don't have any problems, but occaisionally, we find that some people just cannot email users on our server, no matter how hard they try, they get a bounce message like this (email addresses and hostnames have been changed to generic value's);
----- The following addresses had permanent fatal errors -----
<user@domain.tld> (reason: 550 5.1.1 <user@ispconfig.hostname>: Recipient address rejected: User unknown in local recipient table) ----- Transcript of session follows ----- ... while talking to ispconfig.hostname.: >>> DATA <<< 550 5.1.1 <user@ispconfig.hostname>: Recipient address rejected: User unknown in local recipient table 550 5.1.1 <user@domain.tld>... User unknown <<< 554 5.5.1 Error: no valid recipients
The thing I find strangest about this, is that user@domain.tld (the proper users email address on the ispconfig server) seems to be getting converted to user@ispconfig.hostname. ie. the domain name part of the email address is being converted to the hostname of the ispconfig server. I'm not sure if this is relevant, but it seems strange to me.
If I try to test this by sending an email from my personal googlemail account to the same email address, the mail goes through fine, and I cannot replicate the issue the senders are having.
It happens with multiple unrelated accounts, and multiple unrelated domains on the server, with multiple unrelated users with different ISP's sending the emails. Some users never have the problem at all, other users seem to have it a lot. I really don't know where to start with this. Adding to the problem, it's quite difficult to troubleshoot with senders who aren't my customer, but some are cooperative occaisionally, even though I haven't got anywhere with this in the end. At one point when this happened, I deleted the affected site and associated users and domains (DNS records included) from the ISPConfig control panel, emptied the recycle bin, and recreated them. This seemed to fix the problem for a while (I didn't have any compaints from the user), but now it's resurfaced for at least one of these customers. Obviously continually deleting and readding them (forcing them to update their login details) isn't really a good solution, if in fact it does work.
Apologies if I've missed a thread on this, and please feel free to point me in the direction of it if one exists. I hope somebody can help with this, as I have no idea what to do. There isn't really anything useful in /var/log/mail.log only things like;
Nov 17 15:15:32 apollo postfix/local[12940]: 90E3F6204: to=<web48_admin@ispconfig.hostname>, orig_to=<user@domain.tld>, relay=local, delay=5.4, delays=0.15/0/0/5.3, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -f-)
I have tried to odd trick like "postmap /etc/postfix/virtusertable" to rebuild the user table, but it hasn't helped.
Many Thanks In Advance,
Simon