dovecot + ssl

[bsdperson]

Setup: Freebsd 7.2, postfix, dovecot, mutt and thunderbird.

If I use pop3 evertything is ok. If I use pop3s I cannot read any emails using thunderbird from remote. It simply says there are no messages. Using mutt locally reveals plenty of mails.

I suspect this has to do with mail_location in dovecot.conf. Will this change when switching from pop3 to pop3s? Apart from that I am totally lost...

Merry christmas by the way!

[Carpetsmoker]

I don't think it has anything to do with mail_location if POP3 works, this means dovecot if able to find your emails.

Are you using the right port? And is the port open in your firewall?

[J65nko]

From /etc/services:

pop3s           995/tcp         spop3           # pop3 protocol over TLS/SSL
pop3s           995/udp         spop3           # pop3 protocol over TLS/SSL

Does netstat -an -f inet report something LISTENing on port 995?

[bsdperson]

There's no udp, only tcp4. Anyway, I think I need to look deeper into dovecot.conf.

[J65nko]

Please post that output of netstat -an -f inet Out of privacy concerns you can mangle or obfuscate the public IP address parts

Yes it is quite normal that many ports are only actually used for TCP. Although probably never
used they are also reserved for UDP

[bsdperson]

Absolutely, here goes:

~>sudo netstat -an -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0    100 192.168.1.1.22         192.168.1.2.1791       ESTABLISHED
tcp4       0      0 192.168.1.1.995        192.168.1.2.1679       TIME_WAIT
tcp4       0      0 192.168.1.1.445        192.168.1.2.4051       ESTABLISHED
tcp4       0      0 *.139                  *.*                    LISTEN
tcp4       0      0 *.445                  *.*                    LISTEN
tcp4       0      0 *.995                  *.*                    LISTEN
tcp4       0      0 *.110                  *.*                    LISTEN
tcp4       0      0 192.168.1.1.53         *.*                    LISTEN
tcp4       0      0 127.0.0.1.53           *.*                    LISTEN
tcp4       0      0 *.22                   *.*                    LISTEN
tcp4       0      0 *.25                   *.*                    LISTEN
tcp4       0      0 *.21                   *.*                    LISTEN
udp4       0      0 192.168.1.1.138        *.*
udp4       0      0 192.168.1.1.137        *.*
udp4       0      0 *.138                  *.*
udp4       0      0 *.137                  *.*
udp4       0      0 192.168.0.10.57153     85.21.78.91.123
udp4       0      0 192.168.1.1.53         *.*
udp4       0      0 127.0.0.1.53           *.*
udp4       0      0 *.67                   *.*
udp4       0      0 192.168.0.10.63240     84.2.42.31.123
udp4       0      0 192.168.0.10.60711     83.229.210.18.123
udp4       0      0 192.168.1.1.123        *.*
udp4       0      0 *.5060                 *.*
udp4       0      0 *.514                  *.*
icm4       0      0 *.*                    *.*

[J65nko]

tcp4       0      0 *.995                  *.*                    LISTEN

Ok it is there LISTENing.

To check whether packets are arriving on that port open up another xterm or console
and start tcpdump.:

# tcpdump -ni fxp0 -vv 'port 995'

Replace the 'fxp0' by the NIC which you have. Then open up the TLS/SSL connection and see whether tcpdump shows anything arriving.

If they arrive, check your firewall rules, that you are not accidently blocking port 995 traffic.

In case you are using 'pf' and a 'block log all' rule, you can check packet blockage with

# tcpdump -eni pflog0 -s 128

In yet another console, of course.