Postfix not receiving mail from email but does from sendmail?

Question

I'm trying to forward mail from my server (lets call it tacobell.com) to an external GMail account using postfix. I was following this tutorial.

The problem is when I send mail using another GMail or yahoo account to [email protected], and I check var/log/mail.info, nothing shows up.

However when I use sendmail in the terminal and send to the same address I get the following written into the log as well as the mail actually sending and ending up in my inbox:

Jan  4 00:02:48 Machine postfix/local[6520]: 6C82DB80C4A: to=<[email protected]>, relay=local, delay=0.01, delays=0/0/0/0.01, dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION")
Jan  4 00:02:48 Machine postfix/qmgr[6497]: 6C82DB80C4A: removed
Jan  4 00:09:58 Machine postfix/pickup[6496]: B206CB80C46: uid=0 from=<root>
Jan  4 00:09:58 Machine postfix/cleanup[6540]: B206CB80C46: message-id=<20140104050958.B206CB80C46@Machine>
Jan  4 00:09:58 Machine postfix/qmgr[6497]: B206CB80C46: from=<[email protected]>, size=265, nrcpt=1 (queue active)
Jan  4 00:09:59 nightMachine postfix/smtp[6542]: B206CB80C46: to=<[email protected]>, orig_to=<[email protected]>, relay=gmail-smtp-in.l.google.com[74.125.142.26]:25, delay=14, delays=13/0/0.22/0.69, dsn=2.0.0, status=sent (250 2.0.0 OK 1388812199 qd7si6471164igb.62 - gsmtp)
Jan  4 00:09:59 Machine postfix/qmgr[6497]: B206CB80C46: removed

Is there a reason for this? How would I fix it?

postfix/virtual:

[email protected] [email protected]

Main.cf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = Machine
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = tacobell.com, Machine, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = mail/


#added the following for mail server :O!!
virtual_alias_domains = tacobell.com 
virtual_alias_maps = hash:/etc/postfix/virtual

Result when I do a dig tacobell.com mx query in terminal:

;; ANSWER SECTION:
tacobell.com.        21600   IN      MX      10 mail.tacobell.com.

telnet tacobell.com 25

Connected to tacobell.com.
Escape character is '^]'.
220 Machine ESMTP Postfix (Ubuntu)

Solution

Gah! Terribly sorry for wasting everyone's time. The problem was a very simple error I made because of my ignorance. From the same question on another Stack Exchange site:

You've set your MX record to "mail.example.com". That means that when any mailserver tries to send mail to you, they will do a DNS lookup to find mail.example.com. Since that doesn't exist, the sending system doesn't know where to send the email. To fix this, do either of the following two things:

1. Remove your MX record entirely. As long as you don't have an MX record, the sending system will instead do a DNS lookup for example.com, and since that does resolve to the server running your mailserver, that will work.
2. In addition to the MX record, create an A or CNAME record for mail.example.com.

It should look like his for an A record:

mail     A     127.0.0.1

(except, of course, the IP address should be the actual IP of the server, not the loopback address)

and like this for a CNAME:

mail     CNAME example.com.

Comments

[psusi]

I'm not following your question.. what are you using instead of sendmail?

[bnynn]

sorry for not clarifying, I used another gmail account and yahoo account, both did not seem to register into the log file.

[psusi]

And did you get a reply saying the message could not be delivered? Did you set up the MX record for tacobell.com so that the rest of the world can find your mail server?

[bnynn]

I would assume so. After querying dig tacobell.com mx I recieved one answer with the record mail.tacobell.com

[bnynn]

Yes it is to have the server forward all emails to that account for convenience. I updated the question with my main.cf postfix/virtual and results from doing a dig query. Thanks.

[psusi]

@douggro, no it doesn't bypass postfix, otherwise you wouldn't see postfix handling the message in its logs.

[douggro]

@bnynn Try commenting out your mynetworks entry and adding mynetworks_style=host. I believe your config has Postfix only listening to your loopback and won't catch any incoming mails to forward back out.

[douggro]

@psusi Doh! You're right. It worked because it was originating internally..

[bnynn]

@douggro still doesn't work.. Could it possibly be the fault of google or yahoo?

[douggro]

@bnynn Unlikely. Postfix answered your telnet session, but you're not getting connections from other SMTP servers. Did you initiate that telnet session from the server itself, or an outside machine? Following the telnet command, it should have returned Trying xx.xx.xx.xx which should be your public IP; if it returned an internal IP, we can't tell if Postfix is picking up external connections. Check this part of my Postfix config - you might try running that and see if you can get external connections.

[psusi]

I figured it was a DNS or firewall problem, though gmail should have bounced the message back to you with a delivery failure notice.

[bnynn]

I think google puts them on some kind of a hold... After finding that I did have an mx record for mail.tacobell.com but as they were unable to resolve mailserver, I think they put it on some kind of a queue until the mailserver resolved. The way I know this is because I now have test messages I sent from yesterday flooding my inbox today haha.

[Alexey Ce]

also, you can't use tacobell.com, you need to register your own domain, or even a sub-domain. no-ip.com will give you a subdomain for free, and will even let you enter the mx record on their site.