Postfix refusing relay (554), apparently authorization is not working.
 

Hello all.

I am trying to install a postfix server, which only purpose is to relay mail from clients in smart phones and outside our intranet. For this, I have installed dovecot/postfix as instructed here: Centos - Postfix and here: Centos Posfix SASL.

When trying to use the relay, it rejects the mails with a
554 5.7.1 <myself@gmail.com>: Relay access denied
message. Since I have already reviewed it, I think that the issue is that the message is not authenticated, since the usual message is missing in the logs. I mean, even as I have recieved a succesful authentication message in the above example, there is not message relating the authentication occurring in the logs. I have tried the same using the sasl library, and the very same thing is ocurring. Any ideas?

Thanks in advance,
Chilango

Please find attached logs and relevant configuration files. Logs and configuration files sanitized using example.com for my local domain, myself@ as an user example.

Testing authorization and relaying:
Logs for the above example. Please note that the usual "...client=whatever [IP ADDRESS], sasl_method=PLAIN..." line is missing, although the server answered with succesful authentication.
Postfix configuration:
Relevant Dovecot configuration:

@ Reply
 

Hi cchilaquil,

There should be line in main.cf related to protocols I did not see that line in your configuration. Add the following line to your configuration:

This will provide both IPv4 and IPv6 protcols for your email service.

Another thing to check is mx record for this server. Did you configure mx record to point to your mail server in DNS? As I was not able to get mx record information for your server on the internet. Remember I tried to find the mx record for the hostname which I get after performing reverse lookup for IP 201.147.152.157

You can also check the current MTA in use. Type the following command to check:

If you think that the issue is with sasl authentication then did you try it without sasl authentication to see if you get the same error.

T3RM1NVT0R,

Thanks for your attention and valuable suggestions. I added the inet_protocols line to the postfix config, but still the same problem is present.

I have not added MX records for this server, as this particular server is not intended to receive mail; all mail addressed to the domain is managed by the main gateway. The main purpose of this server is just to provide mail relay to remote clients that connect via a private APN/Mobile Network. I think however I would need to add this server to the SPF records, thanks to bring this to my attention.

The output to the alternatives command points to postfix:
When I try without the authentication, the mail is rejected as well. This however, would be normal according to smtpd_recipient_restrictions. If I try connecting from any of the local networks, it works without an issue, both with or without authentication.

@ Reply
 

Could you please how you have set up your email flow. As I can undestand as of now this is an internal server and not responsible for relaying email directly on the internet. There is a gateway which is responsible for relaying email on the internet and receiving email from the internet.

If that is the case could you please let us know from where this server receive/send email. If this server is responsible for sending email to the gateway then this server should be added in allowed list of the gateway for relaying email otherwise gateway will simple drop the email received from this server. If this server is responsible for receiving email from the gateway and distributing it to internal clients then gateway should be configured to relay email via this server. In that case gateway should be added in allow list of this server.

Is your gateway also configured with postfix? If yes, and you want this server to relay email to your gateway then you have change the following params:

In /etc/postfix/main.cf of this server you have to point mydestination to point to your gateway server instead of $mydomain

and on your gateway server you have to edit /etc/postfix/access file to allow this server to relay emails via gateway server.

Remember to take backup of each file that you will edit before making any changes

Hi, T3RM1NVT0R

This particular server is intended just to relay mail from mobile clients directly to the internet, it will not receive any mail. Hence the $mydomain part of the configuration: the mail relayed from this server points to the main gateway for reply purposes, which is just exactly what we intended.

Again, the intention is to expose this server to mobile clients via an APN (from the internet, for all practical purposes) in order to relay mail to the internet. Because of this, authentication is a must; otherwise we would be taking pools as to the time before this server becomes a source of spam.

From the private networks, it is working just ok. It is from a public network that it will deny relaying. I am almost positive it is an issue regarding authentication, because in the log from postfix I never see that it has been authenticated, even as I can see in the console that authentication was succesful. I would expect to see a line like

Jan 1 00:55:40 hercules postfix/smtpd[2465]: connect from unkwown[IP ADDRESS]
Jan 1 00:55:40 hercules postfix/smtpd[2465]: B000DF4C033: client=unknown[IP ADDRESS], sasl_method=PLAIN, sasl_username=myself

Instead, what i am observing is just a connect and never a reference to a sasl method. So, the connection is not authenticated, and the server is quite right in rejecting relaying. The question is why it is not passing authentication tokens, even as in the session opened it said authentication was successful.

Thanks for your attention, and a happy year to all those reading.
Chilango

@ Reply
 

Hi Chilango,

You want this server to be there so that mobile client can relay emails through this server directly to the internet. Not sure how it will be possible without this server have the proper mx record? mx record is not required only to receive mails but to send emails because email website performs reverse look up of the IP from where the email has been generated.

What about sending? How can a you relay from a different server on the internet when it does not have any existence on the internet (I am talking about this server hercules). Your gateway is known on the internet and unless you configure this server to be known on the internet then how can send emails on internet directly from this server.

The only possible way I can think is to relay emails from this server to your gateway server because that will be internal matter and does not require an mx record.

For that as I mentioned previously you should point this server mydestination param to point to your gateway server and configure your gateway server to receive emails from this server and relay it on the internet.

Could you please explain me this in a scenario as to how it works for private network and how you get a deny when you relay to a public network. Basically I am looking for the steps that you perform when sending email via private and public network. Ofcourse, this will require you to let me know how the email flows.

It might be possible that your gateway server is rejecting authentication token. Not necessary that hercules server is not passing authentication token.

It will be good if you can paste the logs for email flow for both private and public network as it can give us good insight as to whats going on.

There is not a MX record for this particular server, but there is a valid, actual MX record for the domain which mail sent from the server points; thus email sent is valid as there is a valid reply address.

Let me explain with an example:

Second attempt, using public ip address:

Now, the first mail can be sent because of permit_mynetworks in the postfix configuration file; it is actually sent to gmail and produces the following raw message:

Even as the original sender is recorded as per STD 10, any reply is correctly sent to the main gateway. That is precisely what we want. Now, the main gateway can manage replies on his own, without caring about sending messages. Just as an aside, making the main gateway managing sending as well would very soon become unmanageable, because of nature of the mails intended to be used. Returning to the problem...

This is the log for the examples above:

Now, for the first example, using the local network, it was correctly authenticated, -even as it was not required- as it is shown in the first line of the log.

But, for the second attempt, there is no log of authentication, even as we received a successful authentication reply. Please note in line 8 of the log that there is no evidence of any sasl activity, and it is recorded as a simple transaction.

Further, I opened the relay for a brief time, in order to check if relaying was working from the external network. It is. So, Why do you think postfix is not authenticating the user?

Thanks,
Chilango

@ Reply
 

I need to get the things straight before I dig into further details. When you telnet this server on a private IP and then send an email via this server it works fine.

However, if you telnet this server on a public IP and try to send an email you get "Relay access denied"

Am I getting the above part correct?

You said you opened up relay. How did you do that I mean the process that you followed to open relay and check?

If my understanding of private and public network stuff is correct then could you please try the following:

Edit this server's /etc/postfix/access file and put the IP address of the client by which you are connecting to this server on public IP address as follows:

Where xxx.xxx.xxx.xxx will be the public IP address of the client by which you are telneting this server. Put the above line at the bottom of the file save and exit. Restart postfix on the server and then give it a try.

@ Reply
 

Another thing that you could try is adding the following under: smtpd_sender_restrictions = permit_sasl_authenticated and then restarting the services.

That is correct, yes.

I commented out smtpd restrictions, restarted postfix, test. As I saw it was working, I uncommented restrictions and restarted postfix.

That worked. I must say that I edited the access file, ran postman -a, and added a line to the postfix configuration referring the access file. (smtpd_client_restrictions = check_client_access hash:/etc/postfix/access). By the way, it worked fine, but still there is no any log of sasl authentication in postfix.

Added as well, did not work. Still the very same situation.

Thanks for reading so far,
Chilango

@ Reply
 

Alright. In that case I would suggest you to go through the following document: http://www.postfix.org/SASL_README.html

The above document explains how you can let the remote client (clients not in the same network as that of your server) to relay emails.

If this were me, I'd break this fault down a little to work out if it's a Postfix config error, or Dovecot - it could be either.

As you are using Dovecot to provide the authentication to Postfix, test Dovecot is working by logging in with user credentials to either its POP or IMAP service (you can test this locally with TELNET, but may have to temporarily allow either ports 110/143 in your firewall). It's really important to do this because I've lost count of the times that Dovecot was not authenticating anything, whilst I was happily blaming Postfix.

There is a typical phenomena with the current Dovecot, common to software in general - but often acute with Linux. I call 'LIVE' (Linux incorrect version examples). This is where all the documentation and examples you can Google refer to an old version, and the software packages has gone through a revision where the configuration options and syntax have been changed. To make matters worse the documentation for the new version fails miserably to bridge the gap. This phenomena It's a royal PITA and the latest Dovecot, I believe, may be a great example of 'LIVE'.

Just as a follow up on the issue.

I finally gave up. Installed postfix and sasl in a new box, and everything is working. I even copied the config from the original box, and it is working on the new box, but still not in the old server. Original setup is still installed, just in case anyone has any idea to track this strange issue. Other things I have tested since the last update:

- Remove dovecot, using just saslauthd for authentication.
- Remove and reinstalling postfix using yum.
- Remove postfix, then reinstall very specific versions from alternative sources (I mean, repositories)
- Remove postfix completely, and compile from sources for 2.3 patch 3 and 2.3 patch 19
- Remove postfix completely, and then compile from sources. At least it particular one "broke" in the particular form that although is configured in the same way for sals, (the one configuration that is posted above, that I have been referring to myself as the reference configuration) when logging into the server using telnet, server will report sasl authentication mechanisms available, but will never allow authentication from an external network, reporting so in the logs. This one has been tested with postfix 2.7 patch 7 and postfix 2.8 path 7, with same results.


So, for reference for anyone willing to track this issue:
Thank you all very much.
Chilango Chilaquil