I have a Postfix mail server running, and I'm trying to understand why emails sent to [email protected]
are actually sent to [email protected]
instead.
On the command line, I send a simple test email:
echo test | mail -s test [email protected]
In maillog
, I see:
Mar 20 23:40:57 some-server sendmail[29680]: r2L3euXm029680: from=root, size=48, class=0, nrcpts=1, msgid=<[email protected]>, 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[29681]: < localhost.localdomain[127.0.0.1]: MAIL From:<[email protected]> SIZE=48 [email protected]
Mar 20 23:40:57 some-server postfix/smtpd[29681]: > localhost.localdomain[127.0.0.1]: 250 2.1.0 Ok
Mar 20 23:40:57 some-server postfix/smtpd[29681]: < localhost.localdomain[127.0.0.1]: RCPT To:<[email protected]>
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 [email protected]
to [email protected]
?
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 protected]
, and it also gets rewritten as [email protected]
, 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.
Thanks.
Edit #1:
If I try sendmail -bt
, and enter check_mail <[email protected]>
, I get this:
...
Canonify2 input: myself < @ example . com >
Canonify2 returns: myself < @ some-server . example . com . >
...
Not sure what that means.
Edit #2:
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).