Just coming over from the other thread which I’ve managed to fix myself…
When I create a user within a virtual server, it automatically creates the user to have a username of loginname.domainname (eg. johnsmith.jsconsulting). Is there a way around this [as you can’t change POP3/FTP login names]? The only name that seems to be immune is the admin account.
Also, I cannot receive or send emails using the mail server on that box. When I attempt to use the mail server for outgoing mail, nothing gets sent out and when someone sends an email to one of my addresses; nothing appears in the inbox. There is no bounce message meaning that the message must have arrived somewhere.
Is there a way around this [as you can't change POP3/FTP login names]?
Of course, usernames are configurable. Look in the Server Template(s) that you use and set the option “Format for usernames that include domain” in the “Mail for domain” section. If you don’t have a lot of virtual servers and don’t need any sort of domain identifier, you can set it to only use domain qualifiers to avoid a username clash. This is set in the Module Configuration in the “Defaults for new domains section”, and the option is labeled “Include domain name in usernames?”
As for the problems…we need to see the maillog or mail.log. There’s no way we can guess what’s happening to mail without some sort of error message.
Whilst I was looking in /var/log/mail.log, I found some interesting lines:
Dec 6 02:04:25 clarent postfix/smtpd: NOQUEUE: reject: RCPT from 122-118-162-197.dynamic.hinet.net[126.96.36.199]: 554 5.7.1 <firstname.lastname@example.org>: Relay access denied; from=<michael78694@MyMainServer.com> to=<email@example.com> proto=SMTP helo=<www.MyMainServer.com>
Dec 6 03:18:17 clarent postfix/smtpd: NOQUEUE: reject: RCPT from unknown[188.8.131.52]: 554 5.7.1 <firstname.lastname@example.org>: Relay access denied; from=<email@example.com> to=<firstname.lastname@example.org> proto=SMTP helo=<none>
Note that I installed this at 1:19am! Gee…these spambots work fast.
These might be more relevant (I have no idea how to interpret this):
Dec 6 03:23:13 clarent postfix/smtp: C0C652218447: host mx1.aanet.com.au[184.108.40.206] said: 450 4.7.1 <email@example.com>: Sender address rejected: Sender domain does not appear to have a SMTP server running on any MX points (in reply to RCPT TO command)
Dec 6 03:23:25 clarent postfix/smtp: C0C652218447: to=<firstname.lastname@example.org>, relay=mx2.eftel.com[220.127.116.11]:25, delay=13, delays=0.04/0.01/12/0.87, dsn=4.7.1, status=deferred (host mx2.eftel.com[18.104.22.168] said: 450 4.7.1 <email@example.com>: Sender address rejected: Sender domain does not appear to have a SMTP server running on any MX points (in reply to MAIL FROM command))
I was still getting similar messages in the log up till 50 minutes ago. Seems to me that the mail is queued somewhere?
Your server thinks it isn’t the end receiver for these domains.
This is probably a DNS problem. What do you get when you lookup the MX record for these domains?
Here’s my interaction with you name server about it:
[root@www procmail]# host -t mx voodootechnologies.com.au voodooland.info
Using domain server:
voodootechnologies.com.au mail is handled by 5 mail.voodootechnologies.com.au.
[root@www procmail]# host mail.voodootechnologies.com.au.
Host mail.voodootechnologies.com.au not found: 2(SERVFAIL)
[root@www procmail]# host mail.voodootechnologies.com.au. voodooland.info
Using domain server:
mail.voodootechnologies.com.au has address 10.0.0.3
Which looks a little fishy, but I don’t know exactly what your network looks like–but 10.0.0.3 is definitely not going to work for anyone that isn’t on your local network. 10.x.x.x networks do not resolve on the public Internet.
It could also be a broken-ness in the Postfix configuration. Do these domains appear in the /etc/postfix/virtual map file?
is what is in that file.
My network is basically a SOHO network - external IP 22.214.171.124 and internal IP range from 10.0.0.1-137 (138 is the gateway).
Hmm…emails seems to have started to accumlate in the invbox on mail2web. Yay.
Probably the nameserver change was just taking its time to filter through?