I have a Postfix mail server running, and I'm trying to understand why emails sent to
firstname.lastname@example.org are actually sent to
On the command line, I send a simple test email:
echo test | mail -s test email@example.com
maillog, I see:
Mar 20 23:40:57 some-server sendmail: r2L3euXm029680: from=root, size=48, class=0, nrcpts=1, msgid=<201303210340.r2L3euXm029680@some-server.example.com>, relay=root@localhost
So I understand that sendmail is used to send the email, and my Postfix server will receive it.
I enabled the verbose option in Postfix, so I have pretty long logs, but the part that strike me as wrong is this:
Mar 20 23:40:57 some-server postfix/smtpd: < localhost.localdomain[127.0.0.1]: MAIL From:<firstname.lastname@example.org> SIZE=48 AUTHemail@example.com Mar 20 23:40:57 some-server postfix/smtpd: > localhost.localdomain[127.0.0.1]: 250 2.1.0 Ok Mar 20 23:40:57 some-server postfix/smtpd: < localhost.localdomain[127.0.0.1]: RCPT To:<firstname.lastname@example.org>
So the From part is OK; I'm testing from root, and the machine hostname is
some-server.example.com, but who changed the
TO email address from
From what I understand from the log, that last line is a command received by Postfix from sendmail. So why is sendmail saying I want to send to that address, when I asked for something else on the command line?
This returns nothing but comments:
grep -ri some-server /etc/mail /etc/postfix
I also tried to send emails to
email@example.com, and it also gets rewritten as
firstname.lastname@example.org, so the problem is with the host, not the user, getting re-written.
I'll be happy to provide more logs if needed. Just let me know what to try and what logs would be useful to understand what is happening.
If I try
sendmail -bt, and enter
check_mail <email@example.com>, I get this:
... Canonify2 input: myself < @ example . com > Canonify2 returns: myself < @ some-server . example . com . > ...
Not sure what that means.
I read somewhere that domains re-writing could be cause by a wildcard MX entry in the domain. I indeed had that, and have since removed it. It didn't resolve the problem, but maybe there is a delay in the propagation (even if dig seems to indicate propagation is now complete).