Emails With Periods Not Working

[samuch]

We've setup several email accounts on a domain with periods "." in them and they are not working properly. They are set to forward only however they do nothing. An example email is samuch.samuch@host.com

Email addresses without the period work just fine and forward as expected.

Any thoughts on where to look or if this is a known issue?

Thanks!

[lrider]

Hello,
I have detected the same problem and also detected the following:

The /etc/passwd file is ¿corrupted?. It has lots of lines with the line splited at the end of the name of the user. Also it repeats the second half of the line lots of times.

Example in the same order it appears on the file:
**********************************************
....
....
:/var/www/web2/user/firstname.lastname:/bin/false
....
....
:/var/www/web2/user/firstname.lastname:/bin/false
....
....
:/var/www/web2/user/firstname.lastname:/bin/false
....
a total of 25 times ....
....
Normal /etc/passwd lines
....
firstname.lastname:x:13038:10002:firstname middlename lastname
:/var/www/web2/user/firstname.lastname:/bin/false
....
....
************************************************** ***
In the /etc/mail/virtusertable everything seems to be ok.

Also when a email is received, if the acount is redirected, the following shows up in the /var/log/maillog file:

"SYSERR(root): forward: no home"

Thank's in advance....Larry.

[till]

Originally Posted by samuch

We've setup several email accounts on a domain with periods "." in them and they are not working properly. They are set to forward only however they do nothing. An example email is samuch.samuch@host.com

Email addresses without the period work just fine and forward as expected.

Any thoughts on where to look or if this is a known issue?

Thanks!

There is no known issue, my personal email addrss contains a dot too. Please post a excerpt of your mail log file with the lines that apper when you send a email to such a account.

[lrider]

Jun 11 18:37:35 ns4 sendmail[4425]: NOQUEUE: connect from rv-out-0708.google.com [209.85.198.240]
Jun 11 18:37:36 ns4 sendmail[4425]: m5BGbZVt004425: from=<javier.net.68@gmail.com>, size=1840, class=0, nrcpts=1, msgid=<2bcbdb9b0806110937q77b60739kf623ccfd74073c8 d@mail.gmail.com>, proto=ESMTP, daemon=MTA, relay=rv-out-0708.google.com [209.85.198.240]
Jun 11 18:37:36 ns4 sendmail[4451]: m5BGbZVt004425: SYSERR(root): forward: no home
Jun 11 18:37:36 ns4 sendmail[4451]: m5BGbZVt004425: to=<antonio.coca@cunef.edu>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=32057, dsn=2.0.0, stat=Sent
Jun 11 18:37:36 ns4 sendmail[4451]: m5BGbZVt004425: done; delay=00:00:01, ntries=1
J

[samuch]

After testing I've found that the problem only happens with email clients. If I use sendmail on the same server or even outside one, it goes through fine:

echo "test" | mail -s testsubject first.last@problemdomain.com

However, I watch the email leave the mail server using a client and it showed as delivered fine. They don't bounce back. The only difference I can think is the server said it converted to MIME first.

lrider, can you test with the sendmail line above and see if it works for you?

Till, can you think of where I can look on the mail server to see where the emails are coming in? The /var/log/mail.err, mail.info, mail.warn are all empty

[falko]

Does the MX record for the domain point to the correct server? You can check that with

dig mx yourdomain.com

[samuch]

I don't think it could be MX related as any email addresses that don't have periods work just fine.

[falko]

Does your /etc/passwd look correct?
What's in /etc/postfix/virtusertable?

[lrider]

Hello,

As I posted before, in my case the /etc/passwd is corrupted and the /etc/virtusertable is OK.

Even thought the /etc/passwd is corrupted, the server is working ok, and only its fauling the "forwarding" that does not work.

It just happens that I have 300 accounts forwarded and they don't work.

Thank's in advance.... Larry.

[lrider]

More data

I have changed a user and checked the log /home/admispconfig/ispconfig/ispconfig.log file and the following shows up:

19.06.2008 - 20:49:04 => INFO - USER:
jmabando:x:12993:10002:Jose Maria Abando Plaza:/var/www/web2/user/jmabando:/bin/false
19.06.2008 - 20:49:04 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 891: setquota -u jmabando 0 0 0 0 -a &> /dev/null
19.06.2008 - 20:49:04 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 892: setquota -T -u jmabando 604800 604800 -a &> /dev/null
19.06.2008 - 20:49:04 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_procmail.lib.php, Line 57: cp -f /root/ispconfig/isp/conf/forward.master /var/www/web2/user/jmabando/.forward
19.06.2008 - 20:49:06 => INFO - USER:
beatrizabascal:x:12994:10002:Beatriz Maria Abascal Alonso-Lamberti
:/var/www/web2/user/beatrizabascal:/bin/false
19.06.2008 - 20:49:06 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 891: setquota -u beatrizabascal 0 0 0 0 -a &> /dev/null
19.06.2008 - 20:49:06 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 892: setquota -T -u beatrizabascal 604800 604800 -a &> /dev/null
19.06.2008 - 20:49:06 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_procmail.lib.php, Line 57: cp -f /root/ispconfig/isp/conf/forward.master /var/www/web2/user/beatrizabascal/.forward
19.06.2008 - 20:49:08 => INFO - USER:
diegoacebal:x:12995:10002iego Acebal de Salas
:/var/www/web2/user/diegoacebal:/bin/false19.06.2008 - 20:49:08 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 891: setquota -u diegoacebal 0 0 0 0 -a &> /dev/null
19.06.2008 - 20:49:08 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 892: setquota -T -u diegoacebal 604800 604800 -a &> /dev/null
19.06.2008 - 20:49:08 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_procmail.lib.php, Line 57: cp -f /root/ispconfig/isp/conf/forward.master /var/www/web2/user/diegoacebal/.forward


Here we can see where the /etc/passwd file starts to get messed up.

Hope this gives you a clue of what is happening.

I also have another thread with the /etc/passwd corrupted file thing and will post also this data since the it may be a problem in common.

Thank's in advance.....Larry.