0

Dovecot reports logins when trying to send (via T'bird). One of the online email testing sites reported: Server 'HELO' line: 220-mail.mydomain.tld ESMTP Postfix so we know the SMTP service is ready, but follows with this: Warning: Expected on ESMTP return code of '250' capabilities code in response to our 'EHLO'. Got '' Sending an email inwards from an external address simply gets a "connection refused" at the sender end and no response or log entry on the server.

Systemctl status postfix.service shows Postfix as running but with a complaint that it cannot connect to 127.0.0.1:11332: fatal: host/service localhost/11332 not found: Device or resource busy.

I do not know if this is a Postfix, Rspamd, Redis or firewall problem, nor even if it is down to a typo such as a missed semicolon, bracket or quote I have failed to find. The vmail database looks sound and Dovecot is obviously accepting from local registered users.

So what I need is an idea of how to fault find this problem, i.e. what to look at and in which order. I have read through the files I installed, the docs for Rspamd and Redis and am at a loss as to what to do next.

Here are the outputs from postconf -n and postconf -M:

append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
inet_interfaces = 127.0.0.1, ::1, xxx.xxx.xxx.xx, xxxx:xxx:xx:xxxx::2
local_recipient_maps = $virtual_mailbox_maps
mailbox_size_limit = 0
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
minimal_backoff_time = 5m
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
mua_relay_restrictions = reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions = permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
myhostname = mail.dominame.net
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
non_smtpd_milters = inet:localhost:11332
postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access
postscreen_blacklist_action = drop
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = ix.dnsbl.manitu.net*2 zen.spamhaus.org*2
postscreen_dnsbl_threshold = 2
postscreen_greet_action = drop
queue_run_delay = 5m
recipient_delimiter = +
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = high
smtp_tls_policy_maps = mysql:/etc/postfix/sql/tls-policy.cf
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/without_ptr reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_milters = inet:localhost:11332
smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/sql/recipient-access.cf
smtpd_relay_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.xxxxxxxx.xxx/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_key_file = /etc/letsencrypt/live/mail.xxxxxxxx.xxx/privkey.pem
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
virtual_alias_maps = mysql:/etc/postfix/sql/aliases.cf
virtual_mailbox_domains = mysql:/etc/postfix/sql/domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql/accounts.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
[root@hostname ~]# 

smtp       inet  n       -       y       -       1       postscreen -o smtpd_sasl_auth_enable=no
smtpd      pass  -       -       y       -       -       smtpd
dnsblog    unix  -       -       y       -       0       dnsblog
tlsproxy   unix  -       -       y       -       0       tlsproxy
submission inet  n       -       y       -       -       smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_relay_restrictions=$mua_relay_restrictions -o milter_macro_daemon_name=ORIGINATING -o smtpd_sender_login_maps=mysql:/etc/postfix/sql/sender-login-maps.cf -o smtpd_helo_required=no -o smtpd_helo_restrictions= -o cleanup_service_name=submission-header-cleanup
pickup     unix  n       -       y       60      1       pickup
cleanup    unix  n       -       y       -       0       cleanup
qmgr       unix  n       -       n       300     1       qmgr
tlsmgr     unix  -       -       y       1000?   1       tlsmgr
rewrite    unix  -       -       y       -       -       trivial-rewrite
bounce     unix  -       -       y       -       0       bounce
defer      unix  -       -       y       -       0       bounce
trace      unix  -       -       y       -       0       bounce
verify     unix  -       -       y       -       1       verify
flush      unix  n       -       y       1000?   0       flush
proxymap   unix  -       -       n       -       -       proxymap
proxywrite unix  -       -       n       -       1       proxymap
smtp       unix  -       -       y       -       -       smtp
relay      unix  -       -       y       -       -       smtp
showq      unix  n       -       y       -       -       showq
error      unix  -       -       y       -       -       error
retry      unix  -       -       y       -       -       error
discard    unix  -       -       y       -       -       discard
local      unix  -       n       n       -       -       local
virtual    unix  -       n       n       -       -       virtual
lmtp       unix  -       -       y       -       -       lmtp
anvil      unix  -       -       y       -       1       anvil
scache     unix  -       -       y       -       1       scache
submission-header-cleanup unix n - n     -       0       cleanup -o header_checks=regexp:/etc/postfix/submission_header_cleanup

I have tried to transcribe this email server from Thomas Leister's excellent email server on Debian Stretch, which I had running successfully elsewhere on Debian. Arch works differently in small but key ways.

Linux mail 5.5.13-arch2-1 #1 SMP PREEMPT Mon, 30 Mar 2020 20:42:41 +0000 x86_64 GNU/Linux
~]# cat /etc/*release*   
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux```
Mike
  • 1
  • 4
  • Your error relates to a milter (mail filter) which the mail server is configured to look for is not running. As this us a non standard port we can only guess as to what its jib is. Try commenting out that line and check mail works, and then look into whatever tutorial you used and see what its doing and work out why the software is not running. (My guess is its some kind of virus or spam filter, but it could be anything). What are you using redis for? – davidgo Apr 06 '20 at 18:58
  • 1
    Actually, looking into it further - it appears rspamd is not running/not bound to localhost:11332 - which my googling tells me is a common/default port for it. Focus your search there - you should be able to telnet localhost 11332" and get a response of some sort when you have solved the problem. – davidgo Apr 06 '20 at 19:03
  • According to the tutorial that you referred to, rspamd is listening on the on the port 11332. So, postfix cant connect to rspamd. Check if rspamd is up and running properly, try to telnet to that port `telnet localhost 11332`. Try to change localhost with 127.0.0.1 in rspamd configuration. Just saw that @davidgo sugested that before. – dexter Apr 06 '20 at 19:43
  • @davidgo @dexter Still got problems but after commenting out 2 lines in /etc/postfix/main.cf, `smtpd_milters = inet:localhost:11332` and `non_smtpd_milters = inet:localhost:11332` I was able to send - but it only got as far as the server. Nothing showing when sending from an external mail client. More to do but progress, thanks. Switching localhost to 127.0.0.1 in /etc/rspamd/local.d/worker-proxy.inc made no difference. At least the Postfix error has changed - now fatal: unknown service: smtp/tcp instead of not finding the port. – Mike Apr 06 '20 at 22:30
  • @mike are you keeping an eye on your maillog file (/var/log/maillog on many dustros). Using tail -f can show what the mail server is logging in real time and could be a very useful tool to you right now. – davidgo Apr 06 '20 at 23:18
  • @davidgo There is no /var/log/ either maillog or mail.log. I've been trying to follow it in the syslog but getting more sense from running systemctl status {pickone}.service where pickone can be dovecot, postfix, rspamd or redis. I'm new to this forum but ssuspect my best next move may be to mark this as resolved and post the clues the resolution has led to as a new question. Reverse DNS is one (two different returns!) domain not recognised is another, haven't had a chance yet to do any tests yet but still suspect postfix-rspamd-redis need some "matchmaking" to make them work nicely together. – Mike Apr 07 '20 at 08:26
  • Im a bit biased, but were it NY call I would not accept the (only) answer a the solution, as I believe it will misinform others. I don't believe you are obligated to accept an answer. With respect of handling logs, do you know that "tail -f /var/log/syslog | grep --line-buffered " rspamd" will show you only entries related to rspamd as they are logged? – davidgo Apr 07 '20 at 08:35
  • @davidgo just the command I was looking for. To continue from my last comment, I am now getting bounce messages. A busy day on other things ahead but as soon as I get the time to go through stuff simply saved for now I believe I'll have enough to get my teeth into and solve some of the glitches myself. Anything tougher I can then wrap up as a separate question in a new thread. – Mike Apr 07 '20 at 09:39
  • On this board, though, if I close this thread does that mean the suggestion submitted as an answer gets accredited with being the correct answer? If so, please post your initial suggestion as an answer and I'll bump it deliberately before closing. It is, without doubt, the solution which has moved me forward to the point I believe is very close to giving me a working, secure, email server. The various other faults are mostly minor glitches, easily resolved given the time to spend on them. – Mike Apr 07 '20 at 09:44

2 Answers2

-1

I think you have port conflicts.

Lets start with the basics and zoom into what could be the issue ... 

1. Do a port  scan ( using nmap - install if you dont have it )  
   on the localhost 

   # nmap -v localhost -p1-9999

2. Do a port scan from the LAN

   # nmap -v ip.address.of.server -p1-9999

The above will tell you whether ALL the ports that should be open ARE open and that you dont have a firewall configuration issue or that programs have conflicting ports.

Next,

3. Check the logs of the services that  you are running. 
   That will shed more light on the issue.

Additionally it would be helpful if you could give us the results of commands ( from a terminal ) below.

4. cat /etc/*release*   
5. uname -a

The above will let us know what OS you are running and if there are any OS specific issues that you may need to look into.

If the above dont yield a clue, then I would suggest running one service at a time - get that to work before adding on another service. This will help us to know which service is the trigger.

MarcoZen
  • 189
  • 1
  • 5
  • The problem is clearly not a port conflict - it is that a milter is not bound to localhost 11332. Most if this info is of little help, and does not answer the question. – davidgo Apr 06 '20 at 18:52
  • @davidgo - why dont you just post yr comment as an answer. i have given my opinion. You can give yours as well. Its a collaborative community. I noticed that replied after me and used my last para in your comment as well. Thats ok. – MarcoZen Apr 06 '20 at 19:21
  • ? Don't understand what you have said re using your last para - I cant see the similarity. posted a comment as I was offering thoughts, rather then solving the problem. Answers are for solutions - comments are for opinions, questions and insights. Also, the purpose of a rating system is to ensure good answers rise to the top. I down voted because I believe your "answer" is not good. Similarly I commented because I hate it when people downvite and don't advise why. – davidgo Apr 06 '20 at 19:30
  • Milters is much closer to where my own suspicions lay. Sorry davidgo, I didn't spot your initial response until I'd written most of what's below. Rspamd and Redis use 6397. Postfix and Rspamd, from what I can figure out, use 11332, 11333 and 11334 and think I remember them being mentioned in the context of milters when first installing. There is consistency in the reported errors at 11332 with Postfix whereas the Redis module (I think it is) in Rspamd complains of not being able to connect with 127.0.0.1 on 6379. – Mike Apr 06 '20 at 19:53
  • The things I am unclear about, this being my first attempt at installing a server for 8 or 9 years, during which time things have changed, are Rspamd and Redis plus how and where Sieve fits into it all. – Mike Apr 06 '20 at 19:54
  • In light of what davidgo has said I'll check through again and also see if I can roll back rspamd.conf and redis.conf. To your question on Redis, it works with Rspamd using Lua modules. I've read that Rspamd replaces a few somewhat dated and now bloated packages, such as Spamassassin, ClamAV and more and it also generates the required DKIM signatures. In using it I tripped over Redis - it's unmissable in the Rspamd context ;-) – Mike Apr 06 '20 at 19:55
  • @MarcoZen I do believe that should you read the OP you'll find the distro name is in the title. Arch is constantly updated, so neither the kernel nor the packages get out of date. There are of course legacy versions available but anybody using one would have highlighted the fact, I am sure. – Mike Apr 07 '20 at 09:51
  • @Mike - You obviously dont seem to be appreciating that someone took the time to answer your call for help which in your words -> So what I need is an idea of how to fault find this problem, i.e. what to look at and in which order <- My suggestions were perfectly valid in this context. With regards to Arch ( its a rolling release ) and other OSes, troubleshooting would be assisted by having specifics. In your own words -> Arch works differently in small but key ways<- hence my comment on getting the OS info. – MarcoZen Apr 09 '20 at 06:04
  • So maybe next time when you raise a desperate call for help , you will at least say "thank you" to those who tried to extend a hand. – MarcoZen Apr 09 '20 at 06:06
  • User davidgo on the other hand is just one of those ego cases who bcos he has more points than me is more interested in pouring water on community collaboration whilst plagiarizing some parts of my answer. – MarcoZen Apr 09 '20 at 06:08
  • @MarcoZen, taking your points in order: I appended the information you asked for at the bottom of my OP. That in spite of wondering at the time what possible difference spotting whether it is latest or LTS could have made in the context of the problem as reported. I did say in the OP that I would be grateful for any and all pointers and I genuinely am, including yours. But somebody edited that sentence out, at which I assumed that direct thanks were out of order on this board. Strictly business only, it seems. (out of characters, continued below) – Mike Apr 10 '20 at 09:01
  • It appeared to me @davidgo was attempting to to assist by keeping answers relevant in order to assist future readers. That appears to me a perfectly reasonable, indeed laudable, way to conduct matters. He hasn't criticised you in any away apart from responding to your, somewhat petulant if I may say so, response to his initial contribution. If you are prone to take umbrage at imagined slights, ought you to be participating in boards where variations in approach as well as different solutions to your own may, quite legitimately, be offered? – Mike Apr 10 '20 at 09:11
  • Your post screamed for help and your lack of appreciation speaks a lot about you. Next time you should post with a less desperate tone and add a disclaimer " I will be ungrateful for all help rendered ". Thats my opinion. We can just disagree and move on. – MarcoZen Apr 10 '20 at 10:50
-1

@davidgo pointed to the way forward, which was what I was looking for. I'd assumed there would be more errors once this initial hurdle was crossed. The answer was to comment out the milter statement, which I found in main.cf.

After commenting out 2 lines in /etc/postfix/main.cf, smtpd_milters = inet:localhost:11332 and non_smtpd_milters = inet:localhost:11332 I was indeed able to see more informative journal responses and began to receive bounce reports, also indicative.

I have already seen several errors which I am capable of fixing without further help, some which I should be able to fix after a little reading as they look straightforward but I am more than a little rusty. I suspect I'll find others and may have to come back with a new question or questions.

Mike
  • 1
  • 4