Re: ISP mail server trying to connect to port 110
On Sat, Apr 28, 2001 at 12:43:58AM +1000, Mark wrote:
> I get packets (6) attempting to connect to me each time after running
> fetchmail to get my mail from my ISP. I have no trouble getting the
> mail. My firewall (iptables) silently drops these packets as it
> recognises them as "new".
> Here are the relevant rules in my firewall:
> iptables -N log_in_new
> iptables -A log_in_new -j LOG --log-level 1 --log-prefix
> iptables -A log_in_new -j DROP
> # 1. Allow us to initiate TCP connections to anywhere
> iptables -A OUTPUT -o $EXT_IF -m state --state NEW,ESTABLISHED,RELATED
> -j ACCEPT
> # 2. No INVALID packets
> iptables -A INPUT -i $EXT_IF -m state --state INVALID -j log_invalid
> # 3. Allow only established and related packets to come in. This
> # Related ICMP error messages, Packets establishing a FTP data
> # and also the udp/tcp requests to DNS servers (udp/tcp port 53)
> iptables -A INPUT -i $EXT_IF -m state --state ESTABLISHED,RELATED -j
> # 4. No one allowed to connect to us
> iptables -A INPUT -i $EXT_IF -m state --state NEW -j log_in_new
> Here is what is typically in my logs after fetching mail:
> Apr 28 00:23:21 debian kernel: incoming_new_::IN=ppp0 OUT= MAC=
> SRC=188.8.131.52 DST=184.108.40.206 LEN=40 TOS=0x00 PREC=0x00 TTL=120
> ID=62726 DF PROTO=TCP SPT=110 DPT=32831 WINDOW=8433 RES=0x00 ACK FIN
> And this is typical of what I get after I send mail:
> Apr 28 00:19:48 debian kernel: incoming_new_::IN=ppp0 OUT= MAC=
> SRC=220.127.116.11 DST=18.104.22.168 LEN=65 TOS=0x00 PREC=0x00 TTL=120
> ID=29432 DF PROTO=TCP SPT=25 DPT=32826 WINDOW=7166 RES=0x00 ACK PSH FIN
> Note, I use other ISPs also for mail retrieval and get none of this.
> Does anyone know why my ISP would be trying to connect after the
> fetchmail daemon has done its job? Is fetchmail just ending too soon
> for it and thus the ISPs mail server is still thinking it is connected?
Note which flags are set on those packets? ACK FIN ...
TCP requires 3-way-handshake setup and a 4-way close.
ACK <- ..These two often piggyback
FIN <- ..with each other
You appear to send a FIN, then close the connection, your client
apppears to not follow the relevant RFC(can't recall which ATM).