Postfix Config - FQDN Hostnames

Using NethServer 7.0 as an SMTP relay at the moment. The issue I have is that I need stop HELO validation due to the systems using it.

To do this on a NethServer instance, you perform the following commands:

vi /etc/postfix/main.cfg

Then, we find the string we need:

/fqdn

Then, we comment out the following strings:

reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,

This then allows email to pass through fine. Is there a way I can make it so the UI when performing changes does not edit the file and re-enable it?

You may use custom templates to apply your config:

http://docs.nethserver.org/projects/nethserver-devel/en/v7/templates.html#local-site-overrides-templates-custom-and-templates-user-custom

1 Like

Thank you Marcus, albeit I am slightly confused. I did skim the document and see what to do.
Essentially (and I am assuming I am wrong) but I make a new directory under /etc/e-smith/custom-templates/etc/postfix/ and create main.cfg here with the template changes I desire?

From here, in the above mentioned directory, I do expand-template /etc/postfix/main.cfg to modify the config, is this correct?

If so, do I simply add the following to my template file (/etc/e-smith/custom-templates/postfix/main.cfg):

# reject_non_fqdn_helo_hostname,
# reject_invalid_helo_hostname,

To have it overwritten?

I just read another answer here, with another config item. To replicate, I used the following:

mkdir -p /etc/e-smith/templates-custom/etc/main.cfg echo # reject_non_fqdn_helo_hostname, # reject_invalid_helo_hostname, > /etc/e-smith/templates-custom/etc/main.cfg

But, would this not just add another entry to the file as it’s not really appending another line? (I am not even sure this is the correct method).

I just again had a look at another post on the community here, which is similar to what I did.

I made a file, added in my comments, and expanded template to no avail. Is there an option via the GUI to bypass this EHLO check if from XYZ network?

Possible solutions:

  • configure SMTP-AUTH in clients,
  • or whitelist their IP addresses
  • or enable access from trusted networks

Please refer to

Email — NethServer 7 Final

If that is not enough, this is an example of a template-custom fragment for “reject_unknown_sender_domain” that can be adapted to your case. The file is /etc/e-smith/templates-custom/etc/postfix/main.cf/02accept_unknown_sender_domain. The last line shouldn’t contain a LF:

{

    #
    # remove reject_unknown_sender_domain rule
    #
 
    @smtpd_sender_restrictions = map { $_ eq 'reject_unknown_sender_domain' ? () : $_ } @smtpd_sender_restrictions;

    '';
}
2 Likes

Hi David,

Thank you very much for your response, it is greatly appreciated. Note that as it currently stands, I had trusted networks set to 10.0.0.0/8 and was still getting blocked. I’ll go and make that file now (and expand-template) and see how we go from there.

As stated in the manual page linked above about Email > SMTP access page:

The Allow relay from trusted networks option allows any client in the trusted networks to send email messages without any restriction.

If it still doesn’t work you need the template!

Thank you David and Marcus, appreciated. I’ll go an approve this as an answer as I have both ‘solutions’ in place.

If this doesn’t work, I’ll let you know (as I need to spin up another 15 across my sites).

Hi @davidep and @mrmarkuz

Under /etc/b-smith/etc/postfix/main.cfg I have 02accept_unknown_sender_domain with the above mentioned parameters.

I also have under trusted networks 10.0.0.0/8, and to be safe, 10.1.169.0/24 for my host. When I go to send an email out the SMTP relay, I get the following error message: Command parameter not implemented. The server response was: 5.5.2 : Helo command rejected: need fully-qualified hostname

Looking back into /etc/postfix/main.cfg the two fields I need/want removed are again there. As soon as I hash them out and restart the postfix service, the email system works fine.

Suggestions? I am eager to get this corrected because I want to replace many enterprise servers with a few of the Nethservers and just have the updates done in line with the subscription model you have.

I just tried sending via mailx and it seemed to work. I’ll need to do some more investigation as this may actually be more of an issue from the application end.

I went and used another SMTP sending tool and received the same error (“504 5.5.2 : Helo command rejected: need fully-qualified hostname”).

Some other tests:

PowerShell Email Tool

    $SMTPServer = "10.129.80.141"
    $Message = New-Object Net.Mail.MailMessage
    $SMTP = New-Object Net.Mail.SmtpClient($SMTPServer)
    $Message.From = "Nethserver@xyz.com.au"
    $Message.To.Add("mn@example.com.au")
    $Message.Subject = "Windows Update Log - $UserShell @ $FQDN"

This did not send via the SMTP relay, but if I pointed it to my old SMTP relay (OpenBSD) it worked fine.

Using Mailx

I was able to confirm the following worked:

echo “Message” | mailx -s “important mail” someone@mydomain.net

Telnet Test on Port 25

I then continued to send an email using telnet, all the relevant steps copied from this guide; this was able to work without an issue.

Using C# Email Tool

I downloaded some other PowerShell form to send email, and tested on another relay; it seemingly worked fine; using the current SMTP service fails.

I am not sure why I can use mailx and even a telnet connection to the server, yet other applications are not able to relay through to them.

The OpenBSD boxes are using smtpd and simply lisetening on ports. We want to setup a list of domains, and point them straight to an external SMTP relay server as a 1:1 pass through. Tomorrow (as I am not at work) I will attempt to send out via a print scanner, and then also out of our DMS system to see. Albeit I imagine I’ll receive the same errors as the tool I was using.

I think I have misinterpreted a setting. Under SMTP Relay options, it looks as though I need to explicitly add the hosts I want to relay from - is that correct?

So under my trusted network(s) I have the following subnets:

  • 10.1.0.0 255.255.0.0
  • 10.0.0.0 255.255.0.0

The host I am trying to send from is 10.1.169.169 and should be under the trusted network.

I have Allow relay from trusted networks already enabled under SMTP access - so why must I specify allowing SMTP relay from a host when using applications?

I surmise this explans why a telnet connection directly to the mail server and using mailx was working as it was sending locally.

Could you advise?

My configuration here is

# postconf -n | grep helo
smtpd_helo_restrictions = check_client_access cidr:/etc/postfix/access.cidr, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostna

So the HELO policy override is possible by listing an IP or network address under etc/postfix/access.cidr.

That file is generated by a template. You could add a fragment

# mkdir -p /etc/e-smith/templates-custom/etc/postfix/access.cidr/
# echo "10.0.0.0/8 OK" >  /etc/e-smith/templates-custom/etc/postfix/access.cidr/90override
# signal-event nethserver-mail-common-save

For individual IP addresses you can list them under Email > SMTP policy


We could list trusted networks in that file, if Allow relay from trusted networks is enabled: what do you think @dev_team? It’s all about relaxing our default policy about HELO restrictions: maybe too restrictive now that we have Rspamd at work…

1 Like

Thank you all, I do appreciate the support in trying to solve this.

When I grep postconf I receive the same output. If I more mynetworks.cidr I am able to see the following:

127.0.0.1/32 OK
10.0.0.0/16 OK
10.1.0.0/24 OK
172.0.0.0/8 OK
192.168.1.0/24 OK

This is under the 10trustednetworks option. I followed your steps and made the fragment as per your code (I did 10.1.0.0/16 as well) and then tested, the same error occurred on both times.

As soon as I explicitly add the IP Address of the server running the scripts/application, the test works fine without an issue.

At the moment I re-did the fragment with 10.1.0.0/8 to encapsulte the 10.1.169.0 network and ensured the access.cidr respected this.

Any other suggestions?

I don’t see any issue on relaxing the current policy.

2 Likes

I suggest to use curl as SMTP client for your tests

https://ec.haxx.se/usingcurl-smtp.html

Please share the command output!

Hi @davidep.
I’m not too sure if the command was correct, or if I have a misconfiguration. In my ‘Email’ option for the SMTP relay I have my domain xyz.com.au which points directly to another relay.

The first command I ran was:

curl smtp://10.129.80.141 --mail-from curltest@xzy.com.au --mail-rcpt mn@xyz.com.au --upload-file testcurl

The result from this was (55) RCPT Failed: 504, which having a look for that error code all I can find is “command not implemented”, so I surmise I was being an idiot on the command.

I have then tried:

curl --url '10.129.80.141:25' --mail-from 'curltest@xyz.com.au' --mail-rcpt 'mn@xyz.com.au' --upload-file test

Which resulted in a different message, as follows:

  1. 0220 netserver.apeagers.local ESMTP PostFix
  2. 5.5.2 Error: Command not recognised
  3. 221 2.7.0 Error: I can break rules too, goodbye

I then added the --insecure option, and the same error returned.

The test file was a default file much like the guide. Not sure if there is anything specific there.

1 Like

Thank you for giving it a try! I suggest to enable the -v flag to see the SMTP transaction.

This is with FQDN helo:

$ curl -v smtp://nethserver.mydomain.example.com/hello.helo.fqdn --mail-from sender@mydomain.example.com --mail-rcpt recipient@otherdomain.example.com -T - <<EOF
From: sender@mydomain.example.com
To: recipient@otherdomain.example.com
Subject: test HELO
Date: $(date -R)

This is a test helo message from davidep

Sincerely,

EOF

Produces:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.1.100...
* TCP_NODELAY set
* Connected to nethserver.mydomain.example.com (192.168.1.100) port 25 (#0)
< 220 nethserver.mydomain.example.com ESMTP Postfix
> EHLO hello.helo.fqdn
< 250-nethserver.mydomain.example.com
< 250-PIPELINING
< 250-SIZE 20000000
< 250-VRFY
< 250-ETRN
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250 DSN
> MAIL FROM:<sender@mydomain.example.com>
< 250 2.1.0 Ok
> RCPT TO:<recipient@otherdomain.example.com>
< 554 5.7.1 <recipient@otherdomain.example.com>: Relay access denied
* RCPT failed: 554
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
> QUIT
< 221 2.0.0 Bye
* Closing connection 0
curl: (55) RCPT failed: 554

The relay is forbidden to non-authenticated clients. As alternative to SMTP/AUTH it is possible to list the client IP in /etc/postfix/access.cidr with the Allow relay from IP addresses option.

But we always require HELO to be FQDN. I think this is too restrictive: I want to propose a NFR that relax this requirement if the client IP is listed in the access.cidr file. Furthermore, if Allow relay from trusted networks is enabled, the trusted networks have to be added to access.cidr too.

This is to fully implement an SMTP/AUTH alternative policy that is based on IP address only.

If I use non-FQDN helo:

$ curl -v smtp://nethserver.mydomain.example.com/helo-no-fqdn --mail-from sender@mydomain.example.com --mail-rcpt recipient@otherdomain.example.com -T - <<EOF
From: sender@mydomain.example.com
To: recipient@otherdomain.example.com
Subject: test HELO
Date: $(date -R)

This is a test helo message from davidep

Sincerely,

EOF

Yields:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.1.100...
* TCP_NODELAY set
* Connected to nethserver.mydomain.example.com (192.168.1.100) port 25 (#0)
< 220 nethserver.mydomain.example.com ESMTP Postfix
> EHLO helo-no-fqdn
< 250-nethserver.mydomain.example.com
< 250-PIPELINING
< 250-SIZE 20000000
< 250-VRFY
< 250-ETRN
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250 DSN
> MAIL FROM:<sender@mydomain.example.com>
< 250 2.1.0 Ok
> RCPT TO:<recipient@otherdomain.example.com>
< 504 5.5.2 <helo-no-fqdn>: Helo command rejected: need fully-qualified hostname
* RCPT failed: 504
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
> QUIT
< 221 2.0.0 Bye
* Closing connection 0
curl: (55) RCPT failed: 504

Thank you @davidp

I ran through the first command, and it worked fine; the email was received. Let me know if you need the exact console output.

Now I suppose this relay was allowed because I already have 10.1.0.0/16 (actually 10.1.169.0/8 presently) as a trusted network and then that setting defined.

Under the access.cidr file, I can see my network is defined correctly, and has OK as an option. I have this as a trusted network, and under the Email tab I have the domain listed with the option relay to another server defined; all filtering is disabled and there is no smart-host defined.

So from a non-technical perspective (mine) applications are failing to send out emails to the SMTP relay as they’re not defined in the Allow Relay location yet fall under the scope of the trusted network.

If I use curl or telnet (or even Powershell's CMDlet) to send a test email, it works; SMTP scanning for printers, other applications and service fail.

For example:

  • Currently my host (10.1.169.169) is not defined in “Allow Relay”;
  • Currently the 2 lines within the postfix config file are present;
  • The access.cidr has my defined network in there.

If I attempt to send an email I get the following bounce back:

Command parameter not implemented. The server response was: 5.5.2 : Helo command rejected: need fully-qualified hostname

If I perform the following I can get it to work:

  • vi /etc/postfix/main.cfg and hash out the two lines
  • systemctl restart postfix

It will work. If I go and inverse this:

  • Re-enable the two lines in the config file and;
  • Restart the service

This will work. What I have noticed is that this added 10.1.169.169 to access.cidr along with 10.1.0.0/8 OK. I went back to trusted networks and defined 10.1.169.0 255.255.255.0 as the subnet and restarted my postfix service, the access.cidr file remained the same.

So for good measure, I rebooted my system. I then looked again and the trusted network remained 10.1.0.0/8 - can we confirm what generates the access.cidr file? Perhaps this hasn’t been updated in all the changes hence why the host isn’t being trusted?

Updated:

  • No host defined under “IP For SMTP Relay” and “Trusted Network Enabled”
  • 2 lines in config file still present
  • 10.0.0.0/8 manually defined in the access.cidr

This seemed to work on numerous tests. How do I go about regenerating this file automatically with the correct networks?