[SOLVED] Postfix refuses to send to any domain, error 554 5.7.1

CWood · 09-12-2014, 05:09 AM

I am trying to configure a mail server, for a site I'm building. I opted to use Postfix for the MTA, and Courier to provide IMAP (if that's relevant at all).

I can receive emails just fine, and checked this both using Telnet to port 25, and by sending an email from my gmail address, both of which were received without issues.

The problems start when I try to send. No matter where I send from (either my mail client, or telnet again), and where I try to send to, regardless of domain, I get a 554 5.7.1 error, "Relay accessed denied." If this were happening to gmail alone, or perhaps some of the other larger webmail providers as well, I would believe that the previous user of this IP (it's an Amazon EC2 Elastic IP) abused it, and had it blacklisted, however the fact that I can receive mails on the server, and the error occurs regardless of receiving domain, leads me to believe that I've misconfigured something.

Here's my main.cf script:

Code:

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = mail.$mydomain
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = all
mydestination =
local_recipient_maps =
unknown_local_recipient_reject_code = 450
maximal_queue_lifetime = 7d
minimal_backoff_time = 1000s
maximal_backoff_time = 8000s
smtp_helo_timeout = 60s
mynetworks_style = host
delay_warning_time = 4h
masquerade_domains = mail.example.com www.example.com
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_maps = mysql:/etc/postfix/mysql_mailbox.cf
virtual_alias_maps = mysql:/etc/postfix/mysql_alias.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_domains.cf
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
mail_spool_directory = /var/spool/mail
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_recipient_limit = 16
smtpd_soft_error_limit = 3
smtpd_hard_error_limit = 12
smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit
smtpd_data_restrictions = reject_unauth_pipelining

smtpd_helo_required = yes
smtpd_delay_reject = yes
disable_vrfy_command = yes
debug_peer_level = 2
debugger_command =
	 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
	 ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.6.6/samples
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES

I've checked already on various spam blacklists, and no, the IP I'm using is not listed. I can confirm that sending to myself works.

Sorry for not being able to provide any more information, I'm relatively new to using Postfix, and have done all I can think to do to resolve this issue, without posting on here. Googling for hours on end didn't yield any useful information (apart from something that broke receiving mails as well, which has since been undone.)

Thanks in advance for any help you can offer,
Connor

Ser Olmy · 09-12-2014, 06:59 AM

Is the 554 error coming from Postfix or the receiving server?

Have you created an SPF DNS record for your domain, indicating that your server is a valid source of mails from the domain in question?

Have you checked the IP address in question against this list?

CWood · 09-12-2014, 09:40 AM

The 554 was coming from (in my test case) Google's servers. I've checked my IP and domain name against that list, and can confirm that no, I have not been blacklisted.

I do not currently have an SPF record in place, however I have done some reading on the subject, and believe that this may be the issue. I am putting it in place now, and will report back once the records have propogated and I can test it fully.

Ser Olmy · 09-12-2014, 09:49 AM

It may indeed be SPF related, but I'm slightly puzzled by the error message itself.

"Relay access denied" usually indicates that you're delivering mail to a server not listed as an MX for the recipient domain, thus necessitating relaying to another server in order to reach the recipient. If you're delivering mail using DNS records rather than using a Smart Host, that just shouldn't happen.

Of course, it could just be Google's mail servers being deliberately ambiguous, or the error message could be related to mail having to be forwarded from an anti-spam frontend to some hidden backend mail server cluster.

CWood · 09-12-2014, 09:57 AM

It may be that I'm misinterpreting the error message here. I've pulled this from /var/log/maillog:

Code:

Sep 12 14:31:20 ip-172-31-9-78 postfix/smtpd[29102]: NOQUEUE: reject: RCPT from <my computer>: 554 5.7.1 <example@gmail.com>: Relay access denied; from=<admin@example.com> to=<example@gmail.com> proto=ESMTP helo=<[192.168.0.182]>

I'm assuming that it was gmail's servers generating the 554 error, as the error itself follows the email address on their servers, however I could be mistaken.

Ser Olmy · 09-12-2014, 10:06 AM

Considering the IP addresses involved, it looks more like Postfix is refusing to relay mail from a local computer to an external recipient.

CWood · 09-12-2014, 10:34 AM

The SPF record has propagated now, however I still receive the same issue. This probably means that the error is local, and lies in one of my configuration files. The fact that the error occurs when telnetting over port 25 would indicate that the error is specific to Postfix, and has nothing to do with Courier IMAP, however as for narrowing the error down further than that, I'm at something of a loss.

CWood · 09-13-2014, 07:47 AM

Okay, I seem to have narrowed the search down significantly, though still can't seem to get anything working perfectly.

After a lot of messing around with smtpd_recipient_restrictions, using the Postfix documentation, I found that overriding reject_unauth_destination with a preceding permit allows mail to be sent anywhere (though reject_unauth_destination is needed). However, this puts Postfix in an open relay configuration, which is the surest way of getting myself on a blocklist I know of.

So, that all means that it is my server generating the 554. As of right now, I have:

Code:

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

however this still seems to generate the 554 error. Furthermore, I can confirm that email sent on the server itself (using telnet localhost 25, rather than telnet example.com 25) works without restriction, because of the permit_mynetworks clause. What this means, as best I understand it, is that I can either send mail from anybody to anybody, or from anybody only to the local server and from the local server to anybody.

What I need, however, is to be able to send from anybody to users on the server, and from users on the server to anybody, without having to "become" the server to send.

I think that was clear, if not let me know and I'll try to reword it.

Ser Olmy · 09-13-2014, 11:49 AM

According to the Postfix documentation, the "permit_mynetworks" directive means "permit any host in networks defined by the $mynetworks variable". You may want to check that $mynetworks actually does list all local (client) IP networks.

You don't seem to define mynetworks in your configuration file, and since you have a mynetworks_style = host setting, $mynetworks will by default only cover the local server. Try changing mynetworks_style to "subnets", or define mynetworks manually.

CWood · 09-13-2014, 11:58 AM

I've managed to fix it, after many a frustrating hour. Turns out, I wasn't specific enough. I should have specified, remote clients should have been possible. I'd assumed that this would have been implicit, when in reality this is not so.

It also turns out that, to properly send emails from remote clients, SASL should be used, and this is where my configuration fell down. I've fixed the problem now, thanks for your help.

Ser Olmy · 09-13-2014, 12:27 PM

Quote:

Originally Posted by CWood

I should have specified, remote clients should have been possible. I'd assumed that this would have been implicit, when in reality this is not so.

It also turns out that, to properly send emails from remote clients, SASL should be used, and this is where my configuration fell down.

The only way to distinguish "genuine" remote clients (with dynamic IP addresses) from random PCs attempting to relay spam, is to require SMTP authentication. Glad to hear you managed to fix it.