SRV Records not visible, can not receive E-Mails

Question

I set up a debian 8.7 linux server with the IP 123...1 and I pointed bla.example.org at it. (www.)example.org points on another Server 123...2. Now I installed mailcow on this server and I am using the domain bla.example.org for it aswell (the mailcow-admin-panel is under mail.bla.example.org). The installation seems to be fine. Everything went without any errors or warnings.

Everything has full functionality, except receiving emails on test@example.org(but I can send emails).

So I want to show you my DNS-Settings:

A RECORDS    
name                         | destination ip
---------------------------------------------
example.org                  | 123...2
www.example.org              | 123...2
bla.example.org              | 123...1
autodiscover.bla.example.org | 123...1
autoconfig.bla.example.org   | 123...1
dav.bla.example.org          | 123...1

AAAA RECORDS
none

MX RECORDS
name        | priority | value
---------------------------------------------
example.org | 5        | bla.example.org       

CNAME RECORDS
none

NS RECORDS
name        | value
---------------------------
example.org | ns1.whois.com
example.org | ns2.whois.com
example.org | ns3.whois.com
example.org | ns4.whois.com

TXT RECORDS
name        | value
------------------------------
example.org | "v=spf1 mx -all"  

SRV RECORDS
name                               | priority | weight | port | value
--------------------------------------------------------------------------------------------
_imap._tcp.bla.example.org         | 0        | 1      | 143  | bla.example.org       
_imaps._tcp.bla.example.org        | 0        | 1      | 993  | bla.example.org      
_caldavs._tcp.bla.example.org      | 0        | 1      | 443  | dav.bla.example.org  
_carddavs._tcp.bla.example.org     | 0        | 1      | 443  | dav.bla.example.org    
_autodiscover._tcp.bla.example.org | 0        | 1      | 443  | autodiscover.bla.example.org

MXtoolbox says, everything is ok, except srv:example.org: it says "DNS Record not found".

Has anyone an idea?

--- EDIT 1 ---

This is my iptables:

root@xxxxxxxxxx:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:587
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 state NEW,ESTABLISHED
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:143
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:993

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

And this is my netstat

root@xxxxxxx:~# netstat -nlp |grep :25
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      17342/master
tcp6       0      0 :::25                   :::*                    LISTEN      17342/master
root@xxxxxxx:~# netstat -nlp |grep :993
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      1/init
root@xxxxxxx:~# netstat -nlp |grep :143
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      1/init

netstat -taupen

root@xxxxxxx:~# sudo netstat -taupen
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 127.0.0.1:10026         0.0.0.0:*               LISTEN      0          1203091898  17342/master
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      109        1197892369  843/mysqld
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      0          1203091763  17342/master
tcp        0      0 127.0.0.1:588           0.0.0.0:*               LISTEN      0          1203091768  17342/master
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      0          1258351074  4754/dovecot
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      0          1203090744  1/init
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          1258343845  4718/apache2
tcp        0      0 127.0.0.1:81            0.0.0.0:*               LISTEN      0          1258343849  4718/apache2
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      0          1203091757  17342/master
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          1197888954  260/sshd
tcp        0      0 127.0.0.1:10040         0.0.0.0:*               LISTEN      112        1203093011  17396/opendkim
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          1203091747  17342/master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          1258343847  4718/apache2
tcp        0      0 0.0.0.0:4190            0.0.0.0:*               LISTEN      0          1258351049  4754/dovecot
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      0          1203090745  1/init
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN      0          1258351075  4754/dovecot
tcp        0      0 127.0.0.1:10023         0.0.0.0:*               LISTEN      0          1197889825  436/postgrey.pid --
tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN      5001       1203089884  17106/python
tcp        0     64 185.xxx.xxx.xxx:22      212.xxx.xxx.xxx:52217   ESTABLISHED 0          1258284102  4644/1
tcp        0      0 185.xxx.xxx.xxx:22      212.xxx.xxx.xxx:50148   ESTABLISHED 0          1255922804  4028/0
tcp6       0      0 :::587                  :::*                    LISTEN      0          1203091764  17342/master
tcp6       0      0 :::465                  :::*                    LISTEN      0          1203091758  17342/master
tcp6       0      0 127.0.0.1:8983          :::*                    LISTEN      113        1203085479  16901/java
tcp6       0      0 :::25                   :::*                    LISTEN      0          1203091748  17342/master

--- Edit 2 ---

Ok, I saw in the dovecot 10-master.conf there are following lines which i edited:

service imap-login {
  inet_listener imap {
    port = 143   <---- "#" removed by me
  }
  inet_listener imaps {
    port = 993   <---- "#" removed by me
    ssl = yes    <---- "#" removed by me
  }

  # Number of connections to handle before starting a new process. Typically
  # the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
  # is faster. <doc/wiki/LoginProcess.txt>
  #service_count = 1

  # Number of processes to always keep waiting for more connections.
  #process_min_avail = 0

  # If you set service_count=0, you probably need to grow this.
  #vsz_limit = $default_vsz_limit
}

Another table which can be useful:

root@xxxxxxxx:~# systemctl -all list-sockets
LISTEN                       UNIT                            ACTIVATES
/run/fcgiwrap.socket         fcgiwrap.socket                 fcgiwrap.service
/run/systemd/initctl/fifo    systemd-initctl.socket          systemd-initctl.service
/run/systemd/journal/dev-log systemd-journald-dev-log.socket systemd-journald.service
/run/systemd/journal/socket  systemd-journald.socket         systemd-journald.service
/run/systemd/journal/stdout  systemd-journald.socket         systemd-journald.service
/run/systemd/journal/syslog  syslog.socket                   rsyslog.service
/run/systemd/shutdownd       systemd-shutdownd.socket        systemd-shutdownd.service
/run/udev/control            systemd-udevd-control.socket    systemd-udevd.service
/run/uuidd/request           uuidd.socket                    uuidd.service
/var/run/clamav/clamd.ctl    clamav-daemon.socket            clamav-daemon.service
0.0.0.0:143                  dovecot.socket                  dovecot.service
0.0.0.0:993                  dovecot.socket                  dovecot.service
kobject-uevent 1             systemd-udevd-kernel.socket     systemd-udevd.service

This is the portscan of bla.example.org

Status  Port    Name    Result  Time (ms)
  21    ftp Filtered    0
  22    ssh Open    130
  23    telnet  Filtered    0
  25    smtp    Open    131
  53    dns Filtered    0
  80    http    Open    1331
  110   pop3    Filtered    0
  111   portmapper, rpcbind Filtered    0
  135   Microsoft RPC services  Filtered    0
  139   netbios Filtered    0
  143   imap    Filtered    0
  389   ldap    Filtered    0
  443   https   Open    131
  445   SMB directly over IP    Filtered    0
  587   msa-outlook Open    130
  1025  IIS, NFS, or listener RFS remote_file_sharing   Filtered    0
  1352  lotus notes Filtered    0
  1433  sql server  Filtered    0
  1723  Point-to-point tunnelling protocol  Filtered    0
  3306  my sql  Filtered    0
  3389  remote desktop  Filtered    0
  5060  Session Initiation Protocol (SIP)   Filtered    0
  5900  Virtual Network Computer display 0  Filtered    0
  6001  X Window server Filtered    0
  8080  webcache    Filtered    0

As you can see here, the imap port 143 is filtered and 993 does not even appear.^

I can connect with telnet:

root@xxxxxxxxxxx:~# telnet 185.xxx.xxx.xxx 143
Trying 185.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

MTAs usually listen only on localhost in the default configuration. Run `netstat -nlp |grep :25` on your mailserver to see which interfaces it listens on. — Gerald Schneider, Sep 15 '17 at 10:13
Regarding `SRV`, presumably you would have to tell mxtoolbox to look up `srv:_imap._tcp.bla.example.org` (ie, the name where the `SRV` record exists). It does seem unrelated to your problem, though. — Håkan Lindqvist, Sep 15 '17 at 10:15
Thank you for your hint! "DNS Record found" @HåkanLindqvist So the configuration of the srv records seems to be ok. — Bernhard, Sep 15 '17 at 10:34
Is there another way to unblock Port 143 / 993? I mean.. i configured it in my iptables that they are accepted ports. but when i check them on yougetsignal.com it says, they are closed. — Bernhard, Sep 15 '17 at 10:39
An MTA is a Mail transport agent. Please run the command I gave earlier on your server and edit the output into your question. — Gerald Schneider, Sep 15 '17 at 10:53
I updated my question @GeraldSchneider I see nothing bad in iptables. But I guess it the server should listen on 143 and 993 aswell, right? — Bernhard, Sep 15 '17 at 15:09
when i do the port-lookup, mxtoolbox says: 143 is filtered and 993 is not even mentioned — Bernhard, Sep 15 '17 at 15:31
I think I identified the problem. Iptables isnt configured properly and blocks 143. — Bernhard, Sep 15 '17 at 21:11

score 3 · Answer 1 · answered Sep 15 '17 at 09:46

3

The SRV record is unlikely to be the culprit here; the MX record is what should be used. And there's one error in those - you have an MX record with preference 20 pointing at "mail.bla.example.com" but there is no corresponding A record. You need to fix that.

If there is any other problem, it's impossible to find without getting the actual domain name.

answered Sep 15 '17 at 09:46

Jenny D

27,780
21
75
114

Thank you Jenny. Oh yes... this is a remaining from one of my tests. I removed that. So what are the IMAP-entries in the SRV good for, if they have no functional effect? BTW: I tried to sent the testmail to test@example.org and it did not work. – Bernhard Sep 15 '17 at 10:03
please review my update. do you have a clue for me? :)) – Bernhard Sep 15 '17 at 16:49

SRV Records not visible, can not receive E-Mails

1 Answers1