On Wed, Sep 3, 2008 at 3:30 PM, mouss <[EMAIL PROTECTED]> wrote:
> show 'postconf -n' _after_ uncommenting the lines. we can't help you
> troubleshoot problems in setups that work!
Enabled in main.cf. Below is my postconf -n:
email:~# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
home_mailbox = mail/
inet_interfaces = all
mailbox_size_limit = 0
mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost
myhostname = email.example.net
mynetworks = 10.1.0.0/16, 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = example.net
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_helo_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_unknown_recipient_domain, reject_unauth_destination,
reject_rbl_client
sbl.spamhaus.org, permit
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
I then tried to send a message out from my client to this gmail
account and show the following:
Sep 3 15:41:23 email postfix/smtpd[2636]: connect from
tunafish.carlwill.com[10.1.1.204]
Sep 3 15:41:23 email postfix/smtpd[2636]: NOQUEUE: reject: RCPT from
tunafish.carlwill.com[10.1.1.204]: 554 5.7.1 <[EMAIL PROTECTED]>:
Relay access denied; from=<[EMAIL PROTECTED]>
to=<[EMAIL PROTECTED]> proto=ESMTP helo=<[10.1.1.204]>
Sep 3 15:41:23 email postfix/smtpd[2636]: disconnect from
tunafish.carlwill.com[10.1.1.204]
If I remove the "restrictions" mail works fine. This email server
<email.example.net> is on the same physical LAN as
tunafish.carlwill.com who is trying to send the email message and
connecting to the email server. I don't know if that has any impact on
this issue. I don't see how or why it should considering that
email.example.com has a properly configured FQDN.
