Topic: User unable to send via submission
==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 0.9.8
- Linux/BSD distribution name and version: CentOS7.4
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Apache
- Manage mail accounts with iRedAdmin-Pro? N
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====I have a user that is unable to send via submission/587 (Windows/Outlook)
With postfix debug turned on, I can see the EHLO is the trigger from being dropped.
Simplified /var/log/maillog
postfix/submission/smtpd[25901]: connect from reverse.dns.for.ip[x.x.x.x]
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 220 my.domain ESMTP Postfix
postfix/submission/smtpd[25901]: < reverse.dns.for.ip[x.x.x.x]: EHLO C2pc
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-my.domain
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-PIPELINING
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-SIZE 15728640
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-ETRN
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-STARTTLS
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-ENHANCEDSTATUSCODES
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250-8BITMIME
postfix/submission/smtpd[25901]: > reverse.dns.for.ip[x.x.x.x]: 250 DSN
postfix/submission/smtpd[25901]: lost connection after EHLO from reverse.dns.for.ip[x.x.x.x]
postfix/submission/smtpd[25901]: disconnect from reverse.dns.for.ip[x.x.x.x]The postconf is as follows:
# postconf -n | grep smtpd_helo_restrictions
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
check_helo_access pcre:/etc/postfix/helo_access.pcre
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostnameSubmission section from /etc/postfix/master.cf
# Submission, port 587, force TLS connection.
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026Which makes perfect sense that "C2pc" is not a FQDN.
However I would not expect every MUA to have a FQDN.
There is "permit_sasl_authenticated", however SMTP Authentication occurs well after the initial HELO/EHLO.
We never get to the Authentication part of the transaction.
Given submission has "smtpd_client_restrictions=permit_sasl_authenticated,reject", then it should be quite reasonable to relax the HELO restrictions.
In my searching, I see that others use "smtpd_helo_restrictions=$mua_helo_restrictions" and then set "mua_helo_restrictions=permit".
I'm not sure if that is the best, but clearly the iRedMail default implementation for submission will always fail for MUA that sends non-FQDN in the HELO.
The purpose for restricting HELO is to stop Spam, however being an authenticated user is usually enough to permit a user to send Spam. Which negates the need for HELO restrictions [IMHO].
Based on my searching, I started a workaround as follows.
The postconf is as follows:
# postconf -n | grep submission_helo_restrictions
submission_helo_restrictions = <<<<<<<<<<<<<<<<<
permit_mynetworks
permit_sasl_authenticated
check_helo_access pcre:/etc/postfix/helo_access.pcre
warn_if_reject reject_non_fqdn_helo_hostname <<<<<<<<<<<<<<<<<
reject_unknown_helo_hostnameNote: this is a new name, and the only difference to smtpd_helo_restrictions is the addition of "warn_if_reject"
I then added this to the master.cf
Submission section from /etc/postfix/master.cf
# Submission, port 587, force TLS connection.
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_helo_restrictions=$submission_helo_restrictions <<<<<<<<<<<<<<<<<
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026The user was able to send an email.
The /var/log/maillog showed the initial status-220, EHLO and the status-250 capabilities as expected, then the transition to STARTTLS and then progressed through the encrypted status-220, EHLO and the status-250 capabilities as expected.
I see that equally the following would work too (not tried):
# Submission, port 587, force TLS connection.
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_helo_restrictions=permit <<<<<<<<<<<<<<<<<
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026---------------------------------
Can you advise if my understanding is correct.
Does this constitute a recommendation to adjust the iRedMail submission/helo restrictions?
Thanks, Rob.
----
Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.