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 thing I find strangest about this, is that [email protected] (the proper users email address on the ispconfig server) seems to be getting converted to [email protected]name. 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; 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
To clear thing out: 1) [email protected] sends mail to [email protected] hosted on your ISPConfig server and [email protected] gets error: ----- The following addresses had permanent fatal errors ----- ... etc. 2) [email protected] sends mail to [email protected] and mail is delivered with no errors [email protected] exists in /etc/postfix/virtusertable ? What HOW-TO did you use for install?
Sorry, I forgot that bit I used The Perfect Setup - Debian Etch (Debian 4.0) HOW-TO. I'm also running ISPConfig 2.2.24, but this problem has occured on the 2 versions prior to that. Debian is fully up to date. Your other points are all correct, yes. The only point I'd make is that [email protected] isn't in /etc/postfix/virtusertable, it's a catchall account for that whole domain. Cheers.
I personaly dont have catchall mail account but I think that it should be listed in /etc/postfix/virtusertable because that account can recive mail sent directly to that account but also recives all other mail sent to same domain.
Well, the account in question is one of a few that the sender tried for this domain. All failed. There are no other user accounts for the site, just a single "admin" account which is a catchall for the domain. @domain.tld web48_admin is listed in /etc/postfix/virtusertable, which I assume refers to the catchall.
Did you install your server exactly as described in the perfect setup guide for your linux distribution?
yes, exactly, as far as I can remember. It was around 10 months ago, now. The only thing I didn't enable was disk quota's.
I've changed my real domain to "domain.tld" but it IS correct in the config file. "apollo" is the hostname of the server. I notice that mydestination is commented out ... could that be it ? Thanks, Simon
you have another mydestination: mydestination = /etc/postfix/local-host-names and this file is generated by ISPConfig post content of /etc/postfix/local-host-names
Ah yes, I didn't spot that. I'd rather not post the contents of /etc/postfix/local-host-names, as it will reveal all the domains of my customers (and there's quite a lot). I'd be ok sending it privately, if it matters. What I can tell you, is that it contains the following (company.tld is my company domain, customer.tld is the domain of the customer having this problem currently); Sorry, I don't mean to be awkward, but I don't think they'd be too happy with me posting any of their info publicly, and I'd rather not expose my company to any embarrassment either (ie. if I've been completely incompetent and screwed something up ). I hope that's OK
Its perfectly understandable why you shouldn't post complete content of local-host-names ... but local-host-names looks ok ...
I cannot imagine what could cause your server to rejects mail from one domain and accepts from others for user on site hosted on server. only if that domain is on blacklist.
Please check if the MX record of your domain is pointing to the correct server: Code: dig mx yourdomain.com
The server and dns ip's are correct. There is one strange thing though, this particular domain has 2 mx records. The primary record points to the customers own Exchange server, the ISPConfig server is a backup MX (and therefore has a lower priority). The primary MX record isn't showing up at all when I check it on both the ispconfig server, and a completely unrelated server. I think this is a separate problem, though and probably has little to do with my problem in the original post. This same issue also occurs for domains where the only MX record is the ISPConfig server. **Edit** The DNS server IP is NOT the ip of the ISPConfig server, by the way. It's the IP for the server hosting company's DNS server, and it is the correct IP for this.
This DNS talk has just made me think. I changed the @ (wildcard) record for the domain in question to point to the ISPConfig server on Wednesday of last week. On Friday, these problems started. I didn't think to connect the two previously. Other domains that have had this problem in the past also have their @ records pointing to the ISPConfig server. I don't see how, but could this be something to do with the problem ? I have just changed the record back to the original IP, just in case that has anything to do with it. Will have to wait a couple of days before we know, I guess.
This is now confirmed as the problem. Senders who were previously getting bounced can now send. It's still strange, as some users have had the wildcard record set for months, so the fact that some can send, some cannot isn't down to DNS propagation. I guess the sending MTA's deal with that kind of DNS setup differently to others. All in all, it isn't an ISPConfig issue - apologies for sending some of you guys round in circles, and thanks for all the help and inspiration. Keep up the good work ! Many Thanks, Simon
