On 2012-03-05 15:53, /dev/rob0 wrote: > On Mon, Mar 05, 2012 at 09:12:00AM +0100, Stanisław Findeisen wrote: >> On 2012-03-04 17:14, /dev/rob0 wrote: >>> On Sun, Mar 04, 2012 at 04:24:44PM +0100, Stanisław Findeisen >>> wrote: >>>> On 2012-03-04 11:26, Michael Tokarev wrote: >>>>> On 04.03.2012 13:30, Stanisław Findeisen wrote: >>>>>> On 2012-03-04 09:20, Stanisław Findeisen wrote: >>>>>>> I am running a small Postfix server, and for a couple of >>>>>>> hours I've been getting: "host ... refused to talk to me: >>>>>>> 421 service not available (connection refused, too many >>>>>>> connections)" for all the outgoing mail, all destination >>>>>>> servers. >>>>>>> >>>>>>> What's wrong? >>>>>>> >>>>>>> I wasn't even able to subscribe to this mailing list: >>>>>>> >>>>>>> Mar 4 00:41:38 k8ux postfix/smtp[2987]: 1462B1F2505: >>>>>>> to=<majord...@postfix.org>, >>>>>>> relay=mail.cloud9.net[168.100.1.7]:25, delay=417, >>>>>>> delays=417/0.02/0.06/0, dsn=4.0.0, status=deferred (host >>>>>>> mail.cloud9.net[168.100.1.7] refused to talk to me: 421 >>>>>>> service not available (connection refused, too many >>>>>>> connections)) >>>>> >>>>> This smells very much like your outgoing SMTP connections >>>>> are being trapped by your ISP and redirected to _their_ >>>>> SMTP server. >>>> >>>> Wha... what a... ??! 8-O >>>> >>>> You say that mail.cloud9.net[168.100.1.7] was in reality my >>>> ISP's network node? I.e., they are doing some kind of man in >>>> the middle attack / IP address spoofing? >>> >>> Respectively: no, sort of, and no. mail.cloud9.net is still on >>> its own IP address, as are the other hosts you tried. It looks >>> like transparent redirection. >>> >>>> Why do you think they should be doing crap like that??! >>> >>> Controlling/limiting outbound abuse in case of spammers on their >>> networks ... this is my guess. But I don't work for your ISP. >>> >>>> It just started to work after some 15 hours or so. ALL >>>> destination servers (the whole queue has been sent out). >>> >>> Given this additional information, it looks like you triggered >>> an automated rate limiting system in the ISP firewall. >>> >>> Review your terms of service and acceptable use policy. Ensure >>> that you're in compliance. Then, talk to the ISP and ask them >>> about it. >> >> It stopped to work again. :-( >> >> My ISP say there are no limits, and that this is a failure of >> theirs. > > They say this is their failure? Or that is is NOT their failure?
They said this *is* their failure, and that they are trying to resolve it. >> They were unable (or not willing) to explain why outgoing TCP >> traffic to ports 25 and 587 (they say this one is a problem too) >> is handled in a different way than other traffic (say TCP 80). > > They told you the same thing happens with 587? Yes. > *boggles* > > Maybe the person you talked to does not know, or lied. Whatever. > Doesn't matter. It looks like it's time to find a different ISP. > > Another WAG: maybe your ISP's upstream provider got tired of > complaints and implemented this redirection upstream. This would > explain why the ISP would not know. > >> I know what TCP/IP is, but I don't know too much about routing >> practice. What do you think they could be doing with this >> traffic and why? >> >> /dev/rob0: what is transparent redirection? Did you mean that my >> Postfix was tricked and talking to my ISP's SMTP server, instead >> of mail.cloud9.net[168.100.1.7] in this case? > > "Tricked" is not the right word. "Hijacked" fits better. > > In railroad terms, think of a switch in the track. The locomotive > driver cannot help but go where the track takes him, and if someone > sets that switch to send him down the wrong track, there he goes! > > In Linux/Netfilter terms, it is the REDIRECT target combined with > some sort of detection: > > iptables -N SmtpRedirect > iptables -A SmtpRedirect -p tcp -m multiport --dports 25,587 \ > -j REDIRECT --to-ports 2525 > iptables -A FORWARD <something to detect abuse> -j SmtpRedirect > > And they'd have a simple daemon listening on 2525/tcp which gives a > "421 service not available ..." banner, then drops the connection, > such as you are seeing. Ok, thanks. > I think tcptraceroute is the tool to check this. While blocked you > could compare port 25 to port 80 on a known host. But the right > answer, for running a mail server, is to use a better ISP. Check on > cheap VPS services for an affordable alternative. Ok, thanks. Or a friend SMTP server to see what gets through. Now it is working again... My bad suspicion is that they are in the process of installing some (more or less crappy) mail intercepting facility (i.e. to spy on users) and that this is probably the government who ordered that. This is Europe (Poland) but do you think such things are uncommon elsewhere? I think they are common. I wonder if you have yet any other guess. -- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/ OpenPGP: E3D9 C030 88F5 D254 434C 6683 17DD 22A0 8A3B 5CC0
