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
> "incoming_new_::"
> 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
> includes:
> # Related ICMP error messages, Packets establishing a FTP data
> connection,
> # 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
> ACCEPT
>
> # 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=139.134.5.142 DST=61.9.158.250 LEN=40 TOS=0x00 PREC=0x00 TTL=120
> ID=62726 DF PROTO=TCP SPT=110 DPT=32831 WINDOW=8433 RES=0x00 ACK FIN
> URGP=0
>
> 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=139.134.5.163 DST=61.9.158.250 LEN=65 TOS=0x00 PREC=0x00 TTL=120
> ID=29432 DF PROTO=TCP SPT=25 DPT=32826 WINDOW=7166 RES=0x00 ACK PSH FIN
> URGP=0
>
> 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.
TCP close:
FIN ->
ACK <- ..These two often piggyback
FIN <- ..with each other
ACK ->
You appear to send a FIN, then close the connection, your client
apppears to not follow the relevant RFC(can't recall which ATM).
Gordon Sadler
Reply to: