[GH-ISSUE #1354] Send mail from postfix satallite to Modoboa Server

kerem commented

2026-02-27 11:15:08 +03:00

Owner

Originally created by @jasonaleski on GitHub (Jan 12, 2018).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/1354

I'm running Modoboa 1.9.1 with Nginx Frontend. Everything has been running great over the past few months. I'm really glad to be running my own server.

Now, I'm attempting to configure a remote postfix server as a satellite (SERVER B) and send mail through my primary mail server (SERVER A). Again, SERVER A can send/receive email no problem. I can connect through Thunderbird (via IMAPS and SMTP-587[STARTTLS]), Webmail and everything seems to be good.

SERVER B (the satellite server) is configured to use a sasl_passwd file. The configs seem to be correct becuase I can make it work with a GoogleMail account, but with an account on SERVER A. When I telnet into SERVER A:587, I do not see "250-AUTH PLAIN LOGIN" as an option. I type STARTTLS, then attempt to authenticate, but it immediately closes the connection. All I see is:
250-PIPELINING
250-SIZE 11534336
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

On SERVER A, here are the logs:
Jan 12 15:53:02 SERVERA postfix/submission/smtpd[3628]: connect from SERVERB[SERVERB_IP]
Jan 12 15:53:02 SERVERA postfix/submission/smtpd[3628]: Anonymous TLS connection established from SERVERB[SERVERB_IP]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 12 15:53:02 SERVERA postfix/submission/smtpd[3628]: disconnect from SERVERB[IP] ehlo=2 starttls=1 quit=1 commands=4

On SERVER B (satellite server), here are the logs:
Jan 12 15:53:01 SERVERB postfix/qmgr[6020]: 613163FD38: from=USER@SERVERB.local, size=399, nrcpt=1 (queue active)
Jan 12 15:53:01 SERVERB postfix/smtp[9461]: warning: SERVERA[SERVERA_IP]:587 offered no supported AUTH mechanisms: 'PLAIN'
Jan 12 15:53:01 SERVERB postfix/smtp[9461]: warning: SERVERA[SERVERA_IP]:587 offered no supported AUTH mechanisms: 'PLAIN'
Jan 12 15:53:01 SERVERB postfix/smtp[9461]: 613163FD38: to=REMOVED@REMOTEHOST.COM, relay=SERVERA[SERVERA_IP]:587, delay=1134, delays=1133/0.03/0.29/0, dsn=4.7.0, status=deferred (SASL authentication failed: server SERVERA[SERVERA_IP] offered no compatible authentication mechanisms for this type of connection security)

Other than changing a few certificate keys during the initial SERVER A install, the only other modification I've done was disable postscreen due to mail getting delayed 30+ minutes.

I'm really struggling with where the problem is at. I've tried adjusting some main.cf settings on my primary mail server, but nothing has worked. Can someone point me in a direction?

Originally created by @jasonaleski on GitHub (Jan 12, 2018). Original GitHub issue: https://github.com/modoboa/modoboa/issues/1354 I'm running Modoboa 1.9.1 with Nginx Frontend. Everything has been running great over the past few months. I'm really glad to be running my own server. Now, I'm attempting to configure a remote postfix server as a satellite (SERVER B) and send mail through my primary mail server (SERVER A). Again, SERVER A can send/receive email no problem. I can connect through Thunderbird (via IMAPS and SMTP-587[STARTTLS]), Webmail and everything seems to be good. SERVER B (the satellite server) is configured to use a sasl_passwd file. The configs seem to be correct becuase I can make it work with a GoogleMail account, but with an account on SERVER A. When I telnet into SERVER A:587, I do not see "250-AUTH PLAIN LOGIN" as an option. I type STARTTLS, then attempt to authenticate, but it immediately closes the connection. All I see is: 250-PIPELINING 250-SIZE 11534336 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN On SERVER A, here are the logs: Jan 12 15:53:02 SERVERA postfix/submission/smtpd[3628]: connect from SERVERB[SERVERB_IP] Jan 12 15:53:02 SERVERA postfix/submission/smtpd[3628]: Anonymous TLS connection established from SERVERB[SERVERB_IP]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Jan 12 15:53:02 SERVERA postfix/submission/smtpd[3628]: disconnect from SERVERB[IP] ehlo=2 starttls=1 quit=1 commands=4 On SERVER B (satellite server), here are the logs: Jan 12 15:53:01 SERVERB postfix/qmgr[6020]: 613163FD38: from=<USER@SERVERB.local>, size=399, nrcpt=1 (queue active) Jan 12 15:53:01 SERVERB postfix/smtp[9461]: warning: SERVERA[SERVERA_IP]:587 offered no supported AUTH mechanisms: 'PLAIN' Jan 12 15:53:01 SERVERB postfix/smtp[9461]: warning: SERVERA[SERVERA_IP]:587 offered no supported AUTH mechanisms: 'PLAIN' Jan 12 15:53:01 SERVERB postfix/smtp[9461]: 613163FD38: to=<REMOVED@REMOTEHOST.COM>, relay=SERVERA[SERVERA_IP]:587, delay=1134, delays=1133/0.03/0.29/0, dsn=4.7.0, status=deferred (SASL authentication failed: server SERVERA[SERVERA_IP] offered no compatible authentication mechanisms for this type of connection security) Other than changing a few certificate keys during the initial SERVER A install, the only other modification I've done was disable postscreen due to mail getting delayed 30+ minutes. I'm really struggling with where the problem is at. I've tried adjusting some main.cf settings on my primary mail server, but nothing has worked. Can someone point me in a direction?

kerem closed this issue

2026-02-27 11:15:09 +03:00

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@ghost commented on GitHub (Jan 12, 2018):

You can't use telnet with starttls, use openssl instead

openssl s_client -starttls smtp -crlf -connect SERVER_A:587

@ghost commented on GitHub (Jan 12, 2018): You can't use telnet with starttls, use openssl instead ```shell openssl s_client -starttls smtp -crlf -connect SERVER_A:587 ```

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 12, 2018):

I appreciate the quick reply. I did make some progress. Using the openssl client (just was focused on telnet and didn't think about the SSL part), I did find a problem with the SSL Certificates where they were not including one of the intermediate certs. I've corrected that.
I'm also seeing the AUTH PLAIN
250-PIPELINING
250-SIZE 11534336
250-ETRN
250-AUTH PLAIN
250-AUTH=PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

However when I attempt to issue the manual email commands, I get an "235 2.7.0 Authentication successful". When I issue the RCPT TO (after the MAIL FROM), it renegotiates, then kicks me off (from SERVER B). When I try to send a message from the command line using the "mail" command, I see a "offered no supported AUTH mechanisms: 'PLAIN'" error and then a (SASL authentication failed: server offered no compatible authentication mechanisms for this type of connection security). On the Primary Mail server, I see the connect, TLS connection and disconnect, but no authentication attempt.

@jasonaleski commented on GitHub (Jan 12, 2018): I appreciate the quick reply. I did make some progress. Using the openssl client (just was focused on telnet and didn't think about the SSL part), I did find a problem with the SSL Certificates where they were not including one of the intermediate certs. I've corrected that. I'm also seeing the AUTH PLAIN 250-PIPELINING 250-SIZE 11534336 250-ETRN 250-AUTH PLAIN 250-AUTH=PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN However when I attempt to issue the manual email commands, I get an "235 2.7.0 Authentication successful". When I issue the RCPT TO (after the MAIL FROM), it renegotiates, then kicks me off (from SERVER B). When I try to send a message from the command line using the "mail" command, I see a "offered no supported AUTH mechanisms: 'PLAIN'" error and then a (SASL authentication failed: server offered no compatible authentication mechanisms for this type of connection security). On the Primary Mail server, I see the connect, TLS connection and disconnect, but no authentication attempt.

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@ghost commented on GitHub (Jan 12, 2018):

I've just tried the same on my server and it renegotiates after I send RCPT TO. Try this python script instead it'll connect to your server, login and send a message, it ouputs all the smtp commands and responses to the console.

Just edit the MAIL_SERVER_HOST, USERNAME, PASSWORD and TO_ADDR variables before you use it.

# -*- coding: utf-8 -*-

from __future__ import unicode_literals

try:
    # Python 3
    from email.message import EmailMessage
    PY3 = True
except ImportError:
    # Python 2
    from email.mime.text import MIMEText
    PY3 = False

from smtplib import SMTP


MAIL_SERVER_HOST = "SERVER_A"
MAIL_SERVER_PORT = 587

USERNAME = "USERNAME"
PASSWORD = "PASSWORD"

FROM_ADDR = USERNAME
TO_ADDR = "RECIPIENT"
SUBJECT = "A test message using python :)"
MSG = "This is a test message sent using python :)"


if __name__ == "__main__":
    if PY3:
        msg = EmailMessage()
        msg.set_content(MSG)
    else:
        msg = MIMEText(MSG)

    msg['Subject'] = SUBJECT
    msg['From'] = FROM_ADDR
    msg['To'] = TO_ADDR

    try:
        smtp = SMTP(host=MAIL_SERVER_HOST, port=MAIL_SERVER_PORT)
        smtp.set_debuglevel(True)
        smtp.starttls()
        smtp.ehlo_or_helo_if_needed()
        smtp.login(USERNAME, PASSWORD)
        smtp.sendmail(FROM_ADDR, [TO_ADDR], msg.as_string())
    except Exception as e:
        raise SystemExit(str(e))
    finally:
        if smtp is not None:
            smtp.quit()

@ghost commented on GitHub (Jan 12, 2018): I've just tried the same on my server and it renegotiates after I send RCPT TO. Try this python script instead it'll connect to your server, login and send a message, it ouputs all the smtp commands and responses to the console. Just edit the MAIL_SERVER_HOST, USERNAME, PASSWORD and TO_ADDR variables before you use it. ```python # -*- coding: utf-8 -*- from __future__ import unicode_literals try: # Python 3 from email.message import EmailMessage PY3 = True except ImportError: # Python 2 from email.mime.text import MIMEText PY3 = False from smtplib import SMTP MAIL_SERVER_HOST = "SERVER_A" MAIL_SERVER_PORT = 587 USERNAME = "USERNAME" PASSWORD = "PASSWORD" FROM_ADDR = USERNAME TO_ADDR = "RECIPIENT" SUBJECT = "A test message using python :)" MSG = "This is a test message sent using python :)" if __name__ == "__main__": if PY3: msg = EmailMessage() msg.set_content(MSG) else: msg = MIMEText(MSG) msg['Subject'] = SUBJECT msg['From'] = FROM_ADDR msg['To'] = TO_ADDR try: smtp = SMTP(host=MAIL_SERVER_HOST, port=MAIL_SERVER_PORT) smtp.set_debuglevel(True) smtp.starttls() smtp.ehlo_or_helo_if_needed() smtp.login(USERNAME, PASSWORD) smtp.sendmail(FROM_ADDR, [TO_ADDR], msg.as_string()) except Exception as e: raise SystemExit(str(e)) finally: if smtp is not None: smtp.quit() ```

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 13, 2018):

My exposure to python is limited, and please correct me on error, but it looks like this script is using the SMTP functions of python and not the local Postfix server. The script successfully sent the email. So now I'm back to looking at SERVER B (postfix satellite server) as the culprit. Seeing the output from the script and seeing the responses on the Modoboa/Primary Email server helps. So with that information, it looks like SERVER B is not authenticating properly. Just need to figure out which config! I'll start back up tomorrow.

Just for verification, would you agree that this doesn't appear to be a problem with the Primary Email server/modoboa setup? Resulting in the fault/misconfiguration is somewhere on the ServerB Satellite Server.

Thanks for the python script. I can see that coming in handy in the future!

As I make progress, I'll be sure to post an update if others face this in the future. If not solved in a few days, I can close it out. Even though this isn't a Modoboa Configuration issue, others might find the info helpful.

@jasonaleski commented on GitHub (Jan 13, 2018): My exposure to python is limited, and please correct me on error, but it looks like this script is using the SMTP functions of python and not the local Postfix server. The script successfully sent the email. So now I'm back to looking at SERVER B (postfix satellite server) as the culprit. Seeing the output from the script and seeing the responses on the Modoboa/Primary Email server helps. So with that information, it looks like SERVER B is not authenticating properly. Just need to figure out which config! I'll start back up tomorrow. Just for verification, would you agree that this doesn't appear to be a problem with the Primary Email server/modoboa setup? Resulting in the fault/misconfiguration is somewhere on the ServerB Satellite Server. Thanks for the python script. I can see that coming in handy in the future! As I make progress, I'll be sure to post an update if others face this in the future. If not solved in a few days, I can close it out. Even though this isn't a Modoboa Configuration issue, others might find the info helpful.

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 13, 2018):

Just an update:

I'm now getting an error 553 5.7.1 Sender address rejected: not owned by user.
It still appears the satellite server is not sending the user authentication.

On the Primary Server I see the following:
Anonymous TLS connection established from X
NOQUEUE: reject: RCPT from X
553 Sender address rejected: not owned by user

Looking at the logs, sending email from Thunderbird and from the satellite server (using the same account) vary slightly. When it hits the NOQUEUE, Thunderbird connection shows it's using sasl_method=PLAIN, sasl_username=

Sending mail from the CLI on the Satellite server just rejects it with the 553 message. Appears the SASL mechanism is not being sent.

On another test, I changed the relay=[smtp.gmail.com]:587 and the sasl_passwd and it still sends correctly through gmail.

@jasonaleski commented on GitHub (Jan 13, 2018): Just an update: I'm now getting an error 553 5.7.1 Sender address rejected: not owned by user. It still appears the satellite server is not sending the user authentication. On the Primary Server I see the following: Anonymous TLS connection established from X NOQUEUE: reject: RCPT from X 553 Sender address rejected: not owned by user Looking at the logs, sending email from Thunderbird and from the satellite server (using the same account) vary slightly. When it hits the NOQUEUE, Thunderbird connection shows it's using sasl_method=PLAIN, sasl_username= Sending mail from the CLI on the Satellite server just rejects it with the 553 message. Appears the SASL mechanism is not being sent. On another test, I changed the relay=[smtp.gmail.com]:587 and the sasl_passwd and it still sends correctly through gmail.

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 13, 2018):

So I tried (with success) using a /etc/postfix/generic file with the following contents:

root@SERVERB postmaster@SERVERA
service@SERVERB postmaster@SERVERA

postmap /etc/postfix/generic

The added "smtp_generic_maps = hash:/etc/postfix/generic" to the main.cf file on SERVERB.

Things appear to be sending from the postmaster@SERVERA account as expected. I don't understand the generic_maps, but will dig into this.

@jasonaleski commented on GitHub (Jan 13, 2018): So I tried (with success) using a /etc/postfix/generic file with the following contents: root@SERVERB postmaster@SERVERA service@SERVERB postmaster@SERVERA postmap /etc/postfix/generic The added "smtp_generic_maps = hash:/etc/postfix/generic" to the main.cf file on SERVERB. Things appear to be sending from the postmaster@SERVERA account as expected. I don't understand the generic_maps, but will dig into this.

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@ghost commented on GitHub (Jan 13, 2018):

I think I known what the problem is, in modoboa -> identities edit the user you are using in sasl_password, under the Mail tab add the SERVER B addresses (e.g. root@SERVERB service@SERVERB) to Sender addresses.

@ghost commented on GitHub (Jan 13, 2018): I think I known what the problem is, in modoboa -> identities edit the user you are using in sasl_password, under the Mail tab add the SERVER B addresses (e.g. root@SERVERB service@SERVERB) to `Sender addresses`.

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 14, 2018):

Wow. That was it. All this head banging on desk and it was the Sender Addresses. I completely overlooked that. Before I had tried adding a virtual domain on the server, user account, everything. I even tried to added it as an alias on that account (even though it wouldn't let me). Didn't even dawn on me to try the sender.

Final question. Does anyone know if it is possible to wildcard this field? I haven't searched yet, but I was just curious. If not, I'm happy and just knowing all I need to do is add a sender. I'm still having a hard time getting it through my head that it works fine with a Gmail Account, but not to another Posfix/Modoba server. It's almost as if the authentication takes place first before the lookup on Gmail, but exact opposite with Postfix/Modoba virtual setup.

I also wonder if this same thing is occuring from my IoT device? I just need to know the local account it is acting as.

Big thanks!

@jasonaleski commented on GitHub (Jan 14, 2018): Wow. That was it. All this head banging on desk and it was the Sender Addresses. I completely overlooked that. Before I had tried adding a virtual domain on the server, user account, everything. I even tried to added it as an alias on that account (even though it wouldn't let me). Didn't even dawn on me to try the sender. Final question. Does anyone know if it is possible to wildcard this field? I haven't searched yet, but I was just curious. If not, I'm happy and just knowing all I need to do is add a sender. I'm still having a hard time getting it through my head that it works fine with a Gmail Account, but not to another Posfix/Modoba server. It's almost as if the authentication takes place first before the lookup on Gmail, but exact opposite with Postfix/Modoba virtual setup. I also wonder if this same thing is occuring from my IoT device? I just need to know the local account it is acting as. Big thanks!

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 14, 2018):

Well, found the IoT solution. On the Primary Postfix/Modoba server, I changed the /etc/dovecot/conf.d/10-auth.conf file

FROM: auth_mechanisms = plain
TO: auth_mechanisms = plain login

Now, just wondering if there is a way to somehow wildcard the SQL search or make the authentication take place first and the lookup based on the user loging into the server and not the sender.

@jasonaleski commented on GitHub (Jan 14, 2018): Well, found the IoT solution. On the Primary Postfix/Modoba server, I changed the /etc/dovecot/conf.d/10-auth.conf file FROM: auth_mechanisms = plain TO: auth_mechanisms = plain login Now, just wondering if there is a way to somehow wildcard the SQL search or make the authentication take place first and the lookup based on the user loging into the server and not the sender.

kerem commented

2026-02-27 11:15:09 +03:00

Author

Owner

@jasonaleski commented on GitHub (Jan 16, 2018):

Going to close this out. Haven't completely solved this, but enough to be satisfied.

@jasonaleski commented on GitHub (Jan 16, 2018): Going to close this out. Haven't completely solved this, but enough to be satisfied.

kerem referenced this issue

2026-02-27 12:09:27 +03:00

[PR #1079] [MERGED] DRF 3.6.2 #2114

Rows
Columns

[GH-ISSUE #1354] Send mail from postfix satallite to Modoboa Server #1078