servername _ causes invalid helo for smtp mail sending

[s00500]

Hi everyone,

I have been using this image and want to use a smtp server with it. the problem is though that somehow the servername is an underscore and that causes an invalid helo message...

I have found this in the nginx configuration:

server_name _;

Apparently a similar problem exists also on the nextcloud image and has been reported as an issue

https://github.com/nextcloud/server/issues/14941

Is there a easy workaroud or some better configuration to fix this ?

Greetings and thanks for the otherwise awesome image!

[github-actions[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[s00500]

Ok, I just realised that the nginx config is placed in the persistent /config dir and can easily be edited, nevermind, maybe this could be added to the docs to save some other people some searchtime ?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[s00500]

Could this be added to the docs ?

[chonnymon]

@s00500

+1 for adding to Docs

Thanks for posting, this helped me

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[s00500]

please add this to the docs!

[homerr]

What are we changing in the docs? Let me know so I can make some updates...

[s00500]

A note on troubleshooting emails:

If you get an INVALID HELO error when trying to send an email using bookstack SMTP try the following solution: Link the /config folder to a local volume, run the container, then navigate to the volume -> nginx folder and edit the nginx.conf file. remove the line server_name _; or replace it with your domain: server_name my.wiki.domain.com;

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[s00500]

Not stale!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[s00500]

@homerr can you please add the note ?

[nemchik]

@s00500 can you try setting server_name _; and then replace your php location block with the following:

    location ~ ^(.+\.php)(.*)$ {
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi_params;

        fastcgi_param SERVER_NAME $http_host;
    }

Let me know if this works. I'm seeing this method to be somewhat common practice.

p.s. I'm not positive that SERVER_NAME should be set to $http_host, there might be a better value, but I'm wanting to ensure that setting SERVER_NAME via fastcgi_param works correctly. If so, we may be able to implement an environment variable as a permanent fix.

[s00500]

@nemchik I can confirm that this solution works for me

[nemchik]

@nemchik I can confirm that this solution works for me

Great! Thanks for testing that. I will look into the best way to implement setting fastcgi_param SERVER_NAME <something here>;

This may be tied into a larger effort I'm working on with our nginx base image, which would mean it could be on hold for some time. I'll try to determine if it makes sense to go that direction, or to make an individual method for this image (which could roll out much sooner). Until then, you should have a working solution. We'll keep info updated in this issue as progress is made.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[s00500]

NOT STALE !!!!!!!!!!!!!!!!!!!

[j0nnymoe]

@s00500 is your ! ok?

[s00500]

My install is fine, and I also documented the solution in the beginning of this issue and tested alternative approaches successfully, but my initial request of having this issue documented is not fulfilled as this is still undocumented, making this issue the only place where it is documented. Keeping it open will at least make it easier to find for people. Is there any way you could disable the stale-bot here ? or pin the issue ?

[s00500]

So yes after dismissing the stale-bot for the 5th time on such a simple issue my keyboard seems to have suffered from it haha (just joking, please do not take personal ;-) )

[j0nnymoe]

I believe @nemchik is working on our nginx based images which will include a fix for this issue. I'll check if there is a flag that will make the bot ignore this issue.

[j0nnymoe]

So yes after dismissing the stale-bot for the 5th time on such a simple issue my keyboard seems to have suffered from it haha (just joking, please do not take personal ;-) )

Ha no worries :-) - bot should leave this issue alone now.

[nemchik]

Just to follow up, https://github.com/linuxserver/docker-baseimage-alpine-nginx/pull/84 this is the work being done, but it does not yet include a change to handle this specific issue.

I'm still investigating the difference between fastcgi_param SERVER_NAME $http_host; and fastcgi_param SERVER_NAME $host;

Based on my research it seems $host is the correct value to use and should be safe as a default value. Ref: https://www.php.net/manual/en/reserved.variables.server.php which links to http://www.faqs.org/rfcs/rfc3875.html#:~:text=4.1.14.%20%20SERVER_NAME

See also: https://stackoverflow.com/a/15414811/1384186 tl;dr

• $http_host is set by the request header, and can contain a port.
• $host contains the value of $http_host without the port (unless $http_host is somehow not set, then it falls back to $server_name which we define in the nginx config as _).

there is a separate SERVER_PORT parameter nginx already passes to php, and the CGI spec defines SERVER_NAME in a way that does not mention including the port.