I registered for a free email account with "www.sina.com" in China and
noticed the problem:

"telnet pop.sina.com 110" or access via an email client
- OK within China
- failed outside of China (connection reset after RETR 1 with telnet)

Would really appreciate if any POP3 guru out there could explain why.

/Why Tea

In article <1149260037.438268.16080@j55g2000cwa.googlegroups. com>,
"Why Tea" <ytlim1@gmail.com> wrote:

> I registered for a free email account with "www.sina.com" in China and
> noticed the problem:
>
> "telnet pop.sina.com 110" or access via an email client
> - OK within China
> - failed outside of China (connection reset after RETR 1 with telnet)
>
> Would really appreciate if any POP3 guru out there could explain why.

This doesn't sound like a POP3 issue, it sounds like there's a firewall
blocking the connection. I assume you're aware that the Chinese
government controls the Internet over there, and they're very
restrictive about what's allowed in and out.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

> This doesn't sound like a POP3 issue, it sounds like there's a firewall
> blocking the connection. I assume you're aware that the Chinese
> government controls the Internet over there, and they're very
> restrictive about what's allowed in and out.

Thanks for the answer. I suspected that as well, but if there was a
firewall, why did it allow connection until RETR was issued?

I'm curious how do they restrict accessed from all machines outside of
the country? I also found that this is not the case for free Chinese
pop email providers, e.g. 163.com doesn't have the same problem.

/Why Tea

In article <1149295726.390610.189910@j55g2000cwa.googlegroups .com>,
"Why Tea" <ytlim1@gmail.com> wrote:

> > This doesn't sound like a POP3 issue, it sounds like there's a firewall
> > blocking the connection. I assume you're aware that the Chinese
> > government controls the Internet over there, and they're very
> > restrictive about what's allowed in and out.
>
> Thanks for the answer. I suspected that as well, but if there was a
> firewall, why did it allow connection until RETR was issued?

Oops, I didn't notice that you said that it didn't fail until you tried
to download a message.

Now I have a suspicion that the problem is with Path MTU Discovery;
something may be blocking the ICMP packets that this relies on. If you
try to download a message that's less than 1,400 bytes (including the
headers) does it work?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

> Now I have a suspicion that the problem is with Path MTU Discovery;
> something may be blocking the ICMP packets that this relies on. If you
> try to download a message that's less than 1,400 bytes (including the
> headers) does it work?

I don't really know what Path MTU Discovery is, but will look that up.
Yes, I did try to download a very small message. Have a look at the
log:

RETR 1
+OK 676 octets


Connection to host lost.

Just to repeat the original question, why does it work for connections
within China, but not outside?

/Why Tea

Why Tea writes:
[Barry Margolin suggests:]
>> Now I have a suspicion that the problem is with Path MTU Discovery;
>> something may be blocking the ICMP packets that this relies on. If
>> you try to download a message that's less than 1,400 bytes
>> (including the headers) does it work?

> I don't really know what Path MTU Discovery is, but will look that
> up. Yes, I did try to download a very small message. Have a look at
> the log:

> RETR 1
> +OK 676 octets

So this works, which suggests that the problem is specific to longer
messages. That is typical for Path MTU Discovery problems - only when
a large packet (typically 1500 bytes) is sent does the problem show
up. So this supports Barry's suspicion.

> Connection to host lost.

> Just to repeat the original question, why does it work for connections
> within China, but not outside?

Path MTU Discovery relies on ICMP messages. These ICMP messages are
sent from routers, and basically instruct the sender of large packets
(in your case the POP server) that it must send smaller packets.
Maybe some gateway blocks these ICMP messages coming out of China.

But I doubt that yu have enough samples to know for sure that the
problem is specific to crossing the boundaries of the Chinese
Internet.

Do ICMP traceroutes (Windows tracert, or Unix traceroute with the "-I"
option) work for you with destinations outside China?

As a workaround, you could reduce the TCP MSS (Maximum Segment Size)
that your computer advertises. This would cause the POP server to
send smaller packets and avoid the "black hole". How you would change
the MSS depends on the type of your operating system. To which value
you would set your MSS depends on the MTU bottleneck in your path, but
you can always set it down to a safe value such as 536 bytes. In
practice, values around 1300-1400 bytes should also be safe, and incur
slightly less waste.
--
Simon.

Simon,

Thanks for the detailed explantion. I don't think it works for the
short message. What you see in the log actually shows connection lost
immediately after "RETR 1". Let's have a look at it again (shows only
number of octets, not no message text):

RETR 1
+OK 676 octets
<-- email message not received

Connection to host lost. <-- connection lost immediately
<-- not able to connect again
until
a few minutes later


Let's have a look at the same case (a working case) from within China:

RETR 1
+OK 5718 octets
Received: from YTsToshiba (unknown [222.35.140.90])
by app (Coremail) with SMTP id E0C1Av7tekQPG4sA.3
.... <-- more message text
.... <-- more messag text
------=_NextPart_000_0000_01C6836F.A6CCB580--

..
<-- connection stays
up

/Why Tea

Why Tea writes:
> Thanks for the detailed explantion. I don't think it works for the
> short message. What you see in the log actually shows connection
> lost immediately after "RETR 1". Let's have a look at it again
> (shows only number of octets, not no message text):

> RETR 1
> +OK 676 octets
> <-- email message not received

> Connection to host lost. <-- connection lost immediately
> <-- not able to connect again
> until
> a few minutes later

Right, I missed the "Connection to host lost". In that case the
problem probably has nothing to do with Path MTU Discovery.

The way I understand it, the Chinese parts of the Internet are
separated from the rest of the Internet by some sort of filtering
system - some call it the Great Firewall of China, or, in China
itself, the Golden Shield. In the Wikipedia article about this system
(http://en.wikipedia.org/wiki/Great_Firewall_of_China), I find a
recent entry that says:

Still in May 2006, users have been reporting problems accessing
POP mailboxes in many big mail providers (although POP-over-SSL
works fine). In the last week of May, Google and many of its
services beecame unreachable. It's as yet unconfirmed whether
these are instances of blocking, or something else.

Maybe this could be your problem.
--
Simon.