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

ISP mail server trying to connect to port 110



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?

Thanks.

Mark.



Reply to: