Programs talk to each other
All programs need a way to communicate and they depend on each other. What language (protocol) speaks a program, which transport does it use and with whom does it speak?
Sockets are communication end-points they listen for another program to talk. Network sockets allow remote connections and Unix domain sockets are restricted to local connections. Most network sockets are world accessible (red) but some are restricted to the local server (green).
In this chapter we give you an overview which programs listens to what. Once you have the big picture of your running system we will dive deeper into details.
- ComOverview - Overview
- ComPostfix - Postfix sockets
- ComIredapd - iRedAPD socket
- ComAmavis - Amavis new sockets
- ComClamAV - ClamAV socket
- ComSpamassassin - Spamassassin
- ComDovecot - Dovecot sockets
- ComApache - Apache sockets
- ComMysql - Mysql socket
Network sockets
iRedMail components are listening on the following ports:
World access
Those services can be accessed from the whole world. Security is your best friend!
| tcp port | daemon | description | protocol | communication |
|---|---|---|---|---|
| 25 | postfix | receive email | smtp | world -> postfix |
| 587 | postfix | send email | submission, smtp auth, esmtpa | mua <-> postfix <-> dovecot sasl |
| 110 | dovecot | pop3 access | pop3 | mua -> mailbox |
| 143 | dovecot | imap access | imap | mua -> mailbox |
| 995 | dovecot | pop3s access | pop3 over tls | mua -> mailbox |
| 993 | dovecot | imaps access | imap over tls | mua -> mailbox |
| 80 | apache | web access | http | world -> apache |
| 443 | apache | web access | https | world -> apache |
Local access
Those services are only accessible from your server.
| tcp port | daemon | description | protocol | communication |
|---|---|---|---|---|
| 10024 | amavis new | to content filter | smtp | postfix -> amavis |
| 10025 | postfix | from content filter | smtp | amavis -> postfix |
| 7777 | iredapd | policy filter | Postfix Access Policy Delegation Protocol | postfix <-> iredapd |
| 9998 | amavis new | releasing quarantined mails | AM.PDP | iRedAdmin-Pro (or command line tool) -> amavis |
| 3306 | mysql | database | proprietary | many -> db |
| 24 | dovecot | local mail delivery protocol | lmtp | postfix -> dovecot |
| 4190 | dovecot | manage user's sieve scripts | ManageSieve, rfc5804 | sieve client <-> dovecot sieve |
Unix domain sockets
Another way to communicate is over locally accessible Unix sockets. So far we are aware of those Sockets:
| program | description | prototcol | communication |
|---|---|---|---|
| clamav daemon | virus scanner | ?? | amavis <-> clamav |
How is Spamassassin accessed?
Spamassassin does not run as a daemon. Amavis new and Spamassassin are both written in Perl. The Module Mail::SpamAssassin let's Amavis new call the program directly within its code, no sockets involved.
Firewall / fail2ban
We didn't install firewall rules by iRedMail as we have our own configurations for network protection. It happend to us that we got locked out for imap while configuring thunderbird client. This shouldn't happen to our customers and we disabled fail2ban for that reason.
If you experience connection problems always make sure it's not related to ip blocking caused by your firewall settings or fail2ban!
Troubleshoot sockets
Always make sure the program is started and socket is listening. That's the first thing you should check on a lower level. Let's say your server doesn't receive any emails. We know postfix should listen on tcp port 25:
low level
- login to iRedMail server
- check tcp port: netstat -aonp | grep :25
- ok: tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 13997/master off (0.00/0/0), not a tcp port 25 socket problem!
- no socket, check daemon: service postfix status
- nok: service postfix start
- check tcp port again
- start fails: check logfiles...
higher level
Many user decide whether a service runs according a program's response. We as administrators know there is a chain of involved mechanismen between the end user computer and the server. Which makes it difficult to find the cause of a problem. Again, check always on the lowest level!
Just to let you know about higher level checks:
- use telnet for tcp ports, first local check and after success remote check
- use a command line program wich speaks expected protocol, for network socket first local check after success remote check