LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (http://www.linuxquestions.org/questions/linux-server-73/)
-   -   Postfix refusing relay (554), apparently authorization is not working. (http://www.linuxquestions.org/questions/linux-server-73/postfix-refusing-relay-554-apparently-authorization-is-not-working-921261/)

cchilaquil 12-30-2011 01:35 PM

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:
Code:

myself@Menkalinan:~$ telnet hercules.example.com 25
Trying 201.147.152.157...
Connected to hercules.example.com.
Escape character is '^]'.
220 hercules.example.com ESMTP
ehlo menkalinan.example.com
250-hercules.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth plain AG15c2VsZgB3aGF0ZXZlcg==
235 2.0.0 Authentication successful
mail from: myself@example.com
250 2.1.0 Ok
rcpt to:myself@gmail.com
554 5.7.1 <myself@gmail.com>: Relay access denied
quit

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.
Code:

Dec 30 10:51:09 hercules postfix/anvil[32728]: statistics: max cache size 1 at Dec 30 10:46:17
Dec 30 11:18:21 hercules postfix/smtpd[372]: warning: 189.137.203.91: hostname dsl-189-137-203-91-dyn.prod-infinitum.com.mx verification failed: Name or service not known
Dec 30 11:18:21 hercules postfix/smtpd[372]: connect from unknown[189.137.203.91]
Dec 30 11:19:29 hercules postfix/smtpd[372]: NOQUEUE: reject: RCPT from unknown[189.137.203.91]: 554 5.7.1 <myself@gmail.com>: Relay access denied; from=<myself@example.com> to=<myself@gmail.com> proto=ESMTP helo=<menkalinan.example.com>

Postfix configuration:
Code:

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
myhostname = hercules.example.com
mydomain = example.com
myorigin = $mydomain

inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, localhost.localdomain, hercules.example.com
unknown_local_recipient_reject_code = 550

mynetworks_style = subnet
mynetworks = 192.168.0.0/24, 192.168.1.0/24, 127.0.0.0/8

#relay_domains = $mydestination

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
smtpd_banner = $myhostname ESMTP 

debug_peer_level = 2
debugger_command =
        PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
        xxgdb $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.3.3/samples
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES

smtpd_delay_reject = yes
smtpd_helo_required = yes

smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous

smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit

stmpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_mynetworks, permit

Relevant Dovecot configuration:
Code:

## Dovecot configuration file

auth default {

  mechanisms = plain login 

  passdb pam {
  }

  userdb passwd {
  }

  user = root

  socket listen {
    client {
      path = /var/spool/postfix/private/auth
      mode = 0660
      user=postfix
      group=postfix
    }
  }
}


T3RM1NVT0R 12-30-2011 02:56 PM

@ 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:

Code:

inet_protocols = all
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:

Code:

alternatives --display mta | grep current
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.

cchilaquil 12-30-2011 06:05 PM

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:
Quote:

alternatives --display mta|grep current
link currently points to /usr/sbin/sendmail.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.

T3RM1NVT0R 12-31-2011 07:25 AM

@ 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

cchilaquil 01-01-2012 12:19 PM

Hi, T3RM1NVT0R

Quote:

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.
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

T3RM1NVT0R 01-02-2012 05:43 AM

@ Reply
 
Hi Chilango,

Quote:

This particular server is intended just to relay mail from mobile clients directly to the internet, it will not receive any mail.
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.

Quote:

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.
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.

Quote:

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.
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.

Quote:

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.
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.

cchilaquil 01-02-2012 10:08 AM

Quote:

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.
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:

Code:

myself@Menkalinan:~$ telnet LOCAL PRIVATE NETWORK IP.36 25        #Trying into the intranet
Trying LOCAL PRIVATE NETWORK IP.36...
Connected to LOCAL PRIVATE NETWORK IP.36.
Escape character is '^]'.
220 hercules.example.com ESMTP
ehlo menkalinan.example.com       
250-hercules.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth plain AG15c2VsZgB3aGF0ZXZlcg==                                #This is not required, but still
235 2.0.0 Authentication successful
mail from:myself@example.com
250 2.1.0 Ok
rcpt to:myself@gmail.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
This is just an example email, in order to examine header and route of this particular mail, as sent from hercules using the local network.
.
250 2.0.0 Ok: queued as 287566C60D87
quit
221 2.0.0 Bye
Connection closed by foreign host.
myself@Menkalinan:~$

Second attempt, using public ip address:

Code:

myself@Menkalinan:~$ telnet hercules.example.com 25
Trying HERCULES PUBLIC IP ADDRESS...
Connected to hercules.example.com.
Escape character is '^]'.
220 hercules.example.com ESMTP
ehlo menkalinan.example.com
250-hercules.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth plain AG15c2VsZgB3aGF0ZXZlcg==
235 2.0.0 Authentication successful                                #Please note succesful authentication
mail from:myself@example.com
250 2.1.0 Ok
rcpt to:myself@gmail.com
554 5.7.1 <myself@gmail.com>: Relay access denied
quit
221 2.0.0 Bye
Connection closed by foreign host.

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:

Code:

Delivered-To: myself@gmail.com
Received: by 10.216.164.212 with SMTP id c62cs299383wel;
        Mon, 2 Jan 2012 07:18:19 -0800 (PST)
Received: by 10.236.123.1 with SMTP id u1mr2758006yhh.127.1325517497484;
        Mon, 02 Jan 2012 07:18:17 -0800 (PST)
Return-Path: <myself@example.com>                                  #Note valid return address, due to postfix configuration
Received: from hercules.example.com ([HERCULES PUBLIC IP ADDRESS])
        by mx.google.com with ESMTP id y29si3587132yhl.134.2012.01.02.07.18.16;
        Mon, 02 Jan 2012 07:18:17 -0800 (PST)
Received-SPF: pass (google.com: domain of myself@example.com designates HERCULES PUBLIC IP ADDRESS as permitted sender) client-ip=HERCULES PUBLIC IP ADDRESS;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of myself@example.com designates HERCULES PUBLIC IP ADDRESS as permitted sender) smtp.mail=myself@example.com
Received: from menkalinan.example.com (unknown [LOCAL PRIVATE NETWORK IP.198])
        by hercules.example.com (Postfix) with ESMTP id 287566C60D87
        for <myself@gmail.com>; Mon,  2 Jan 2012 10:00:10 -0600 (CST)
Message-Id: <20120102160025.287566C60D87@hercules.example.com>
Date: Mon,  2 Jan 2012 10:00:10 -0600 (CST)
From: myself@example.com
To: undisclosed-recipients:;

This is just an example email, in order to examine header and route of this particular mail, as sent from hercules using the local network.

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:

Code:

[root@hercules postfix]# tail /var/log/maillog -n 10 > markln -d 2
01: Jan  2 10:00:25 hercules postfix/smtpd[11420]: 287566C60D87: client=unknown[LOCAL PRIVATE NETWORK IP.198], sasl_method=plain, sasl_username=myself
02: Jan  2 10:01:15 hercules postfix/cleanup[11440]: 287566C60D87: message-id=<20120102160025.287566C60D87@hercules.example.com>
03: Jan  2 10:01:15 hercules postfix/qmgr[2717]: 287566C60D87: from=<myself@example.com>, size=505, nrcpt=1 (queue active)
04: Jan  2 10:01:17 hercules postfix/smtp[11444]: 287566C60D87: to=<myself@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.45.27]:25, delay=67, delays=65/0.01/0.88/0.65, dsn=2.0.0, status=sent (250 2.0.0 OK 1325517497 y29si3587132yhl.134)
05: Jan  2 10:01:17 hercules postfix/qmgr[2717]: 287566C60D87: removed
06: Jan  2 10:01:18 hercules postfix/smtpd[11420]: disconnect from unknown[LOCAL PRIVATE NETWORK IP.198]
07: Jan  2 10:01:59 hercules postfix/smtpd[11420]: warning: 189.137.203.91: hostname dsl-189-137-203-91-dyn.prod-infinitum.com.mx verification failed: Name or service not known
08: Jan  2 10:01:59 hercules postfix/smtpd[11420]: connect from unknown[189.137.203.91]
09: Jan  2 10:02:44 hercules postfix/smtpd[11420]: NOQUEUE: reject: RCPT from unknown[189.137.203.91]: 554 5.7.1 <myself@gmail.com>: Relay access denied; from=<myself@example.com> to=<myself@gmail.com> proto=ESMTP helo=<menkalinan.example.com>
10: Jan  2 10:02:47 hercules postfix/smtpd[11420]: disconnect from unknown[189.137.203.91]
[root@hercules postfix]#

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

T3RM1NVT0R 01-02-2012 10:30 AM

@ 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:

Code:

xxx.xxx.xxx.xxx      RELAY
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.

T3RM1NVT0R 01-02-2012 10:54 AM

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

cchilaquil 01-03-2012 08:27 AM

Quote:

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?
That is correct, yes.

Quote:

You said you opened up relay. How did you do that I mean the process that you followed to open relay and check?
I commented out smtpd restrictions, restarted postfix, test. As I saw it was working, I uncommented restrictions and restarted postfix.

Quote:

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 ...
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.

Quote:

Another thing that you could try is adding the following under: smtpd_sender_restrictions = permit_sasl_authenticated and then restarting the services.
Added as well, did not work. Still the very same situation.

Thanks for reading so far,
Chilango

T3RM1NVT0R 01-03-2012 05:03 PM

@ 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.

leslie_jones 01-04-2012 01:47 AM

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'.

cchilaquil 01-12-2012 10:03 AM

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:
Code:

[root@myserver ~]# uname -a
Linux myserver 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:20:37 EDT 2011 i686 athlon i386 GNU/Linux
[root@myserver ~]# /usr/sbin/saslauthd -v
saslauthd 2.1.22
authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap
[root@myserver ~]# postconf -a
cyrus
dovecot
[root@myserver ~]# postconf -d |grep mail_version
mail_version = 2.3.3
milter_macro_v = $mail_name $mail_version
[root@myserver ~]# yum list postfix
Excluding Packages from CentOS-5 - Base
Finished
Excluding Packages from CentOS-5 - Updates
Finished
Installed Packages
postfix.i386                    2:2.3.3-2.3.el5_6                    installed

Thank you all very much.
Chilango Chilaquil


All times are GMT -5. The time now is 11:15 PM.