[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> # 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
> # 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= DST= 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= DST= 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: