Relay access denied when using SMTP to external recipients POSTFIX FREEBSD

Question

i am trying to send an email with my freebsd server using postfix and dbmail to an external adress.

I have noticed the following things:

MYSERVER -> MYSERVER = OKAY

EXTERNALSERVER -> MYSERVER = OKAY

MYSERVER -> EXTERNALSERVER = ERROR(454 4.7.1 Relay access denied)

Why do i get this error? i think it has something to do with my main.cf

####MAIN.CF######
queue_directory = /var/spool/postfix
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
mail_owner = postfix
default_privs = nobody
myhostname = server.domain.nl
mydomain = domain.nl
myorigin = $mydomain
inet_interfaces = all
virtual_transport = dbmail-lmtp:localhost:24
virtual_mailbox_domains = domain.nl
unknown_local_recipient_reject_code = 550
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_helo_required = yes
strict_rfc821_envelopes = 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/local/sbin/sendmail
mailq_path = /usr/local/bin/mailq
setgid_group = maildrop
html_directory = /usr/local/share/doc/postfix
manpage_directory = /usr/local/man
sample_directory = /usr/local/etc/postfix
readme_directory = /usr/local/share/doc/postfix
inet_protocols = ipv4
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination

Solution 1

Isn't that you haven't authenticated properly (via your mail client) to send outbound email or otherwise haven't setup mynetworks such that it will allow all systems within your network to send without authentication?

https://serverfault.com/questions/42519/how-to-correct-postfix-relay-access-denied

Solution 2

I had a similar error message when I set up sendmail as in this thread. For me the problem was that I was authenticating over port 465, which is SMTP with TLS, but the protocol requires TLS to run after authentication, for example over port 25, which is SMTP without TLS.

The solution was to change the port in ~/.authinfo to

machine server.domain.tld login [email protected] port 25 password XYZ

Update: I'm no SMTP expert. My answer is based on my experience and on this thread, where a comment mentioned this rebuttal about my use of port 25 for authentication:

That's not the way SMTP AUTH works: you authenticate and send using the same port, in this case 587.

Solution 3

Historically, SMTP connections to port 25/TCP were used by both email clients (MUAs) to send outgoing mail to their local mail server, or by mail servers (MTAs) to pass email from one mail server to another. No authentication was included as standard. This turned out to be a very bad idea.

To fix the problems caused by this, modern mail servers are usually set up to accept incoming email from clients using port 587. When using this port, authentication is usually mandatory, and TLS encryption (using STARTTLS) is highly recommended.

The port 25 is increasingly dedicated to traffic between "valid" mail servers only, and the validity of a particular mail server is mostly decided by various DNS records.

"Relay access denied" means that you're not currently authorized to send email through the external server to any other mail server, i.e. mail relaying like

YOURSERVER -> EXTERNALSERVER -> THIRD-PARTY-SERVER

will be blocked. If the destination address of the email you're sending matches one of the domains EXTERNALSERVER is directly responsible for, it should still be accepted, unless you're failing other anti-spam checks.

There is a number of various anti-spam tests that other mail servers may apply to an incoming SMTP connection:

• On connection, the connecting host needs to state the hostname it claims to be. The receiving host will perform a reverse DNS lookup for the source IP address: does the name reported by DNS match the name claimed by the connecting host? A regular forward DNS lookup is also performed: does the IP address reported by DNS for that name match the source IP address the connection is actually coming from? This is one of the oldest anti-spam tests. If you fail this test and don't authenticate, you'll be allowed to only send email to the email addresses the destination host is directly responsible for, not to any third parties.

• There are also DNS SPF records which can (optionally) specify which hosts in a particular DNS domain are supposed to send email to the internet. If your domain has a SPF record (try dig domain.name TXT to see) and that record indicates your host is not supposed to be a mail server, and you're not authenticating, the external server may reject your connection attempt completely.

• DNS MX records are another important part of email delivery: they specify the actual hostname of the mail server(s) serving a particular domain. In order to determine where email addressed to [email protected] should be delivered to, email servers will first look up a MX record for domain.example. You can do it yourself with a command like dig domain.example MX. If there are no MX records for a particular DNS domain, there is a fall-back rule: if there is a plain old DNS A record for domain.example and the host in the IP address identified by that A record listens on port 25/TCP, then any emails addressed to that domain will be sent to that IP address. For anti-spam checks, the MX record of the sending host may be checked: the idea is "if you don't look like you're prepared to receive email, you probably should not be sending it either." Because of a large variety of mail server set-ups, this cannot be a hard and fast rule, but it is occasionally used as a small positive/negative factor in the "spam or not?" decisions.

If you are a home user or even a small business, without a static public IP address, an internet service provider may choose to treat you as a simple email client, and only allow you to send outgoing SMTP connections to the provider's email servers only. They may require authentication at that point, or they may allow unauthenticated connection based on the physical structure of their network. In this situation, you can still have your own private mail server; it just needs to send all outgoing email through the provider's mail servers just like a regular email client would. This is sometimes called a "smarthost" configuration, according to the name of the configuration option for it in the classic Sendmail. In modern times, using port 587 and authentication instead of classic unauthenticated port 25 is usually required.

Receiving incoming email in your own server also depends on what is allowed by your internet provider. If your connection is NATted (as home and small-business internet connections increasingly are), receiving incoming connections without opening a fixed tunnel for port 25 through the NAT will be impossible. If your IP address occasionally changes, keeping the email-relevant DNS records always up to date will be critical for the reliability of your email delivery.

Once you have a public static IP address and a DNS domain of your own, you are generally considered "big enough" to have a "real" mail server in the eyes of the internet at large. When setting up a mail server, you should pay very close attention to various types of DNS records relevant for email delivery, and make sure that your server introduces itself (the HELO/EHLO message in the SNMP connections) using the exact name registered for it in the DNS. Also make sure that the reverse DNS record (PTR record, for the IP address -> domain name mapping) is correct.

Comments

[Christopher Thomas]

Yeah this fixed my setup too. Is it because it restricts who can send email and your home computer ip is never on that network? Or can somebody perhaps explain what it means?