![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
First I have to confess that I have no intention to criticize someones' opinions or views. In fact I technically trust them and sometimes admire their valuable insights. Today I experienced pop3 service cutoff. I have several pop3 mail servers in the worldwide Internet and I use them anytime anywhere. Same thing happens inside my company. As of 8 December, the network administrators of my company blocked port number 110. From inside my company it was impossible to retrieve my emails from pop3 servers, which are located outside my company. I called those bad guys (network administrators) and claimed on revocation of blocking. I questioned one of them as to who made that regulation. Their answer was quite simple; they don't have any shield protecting the Intranet from the email viruses attached on emails. On hearing of this answer, I inquired into the truthfulness of this statement. One virus expert (not network) answered in the same way; he has SMTP vaccine server, but has no means to remove attached email viruses delivered by pop3. He suggested to me a relay server, which is a proxy variant. Using relay server, the pop3 - deliverying viruses can be detected and removed, he said. (of course!) I don't know whether any company sells a good solution for pop3 virus detection. Perhaps there are many logically possible ways to solve pop3 virus problem. It may conform to RFCs. For all those possibilities, what I realize and what I've been shocked at is the fact that the network administrators are willingly about to block the pure Internet service or block the end-to-end service (if this company uses relay servers or something like that.). They perfer NAT or NAPT for security reasons. They opened 80 as default, and thanksfully 21, 23, and 25! (Do you expect more? :< ) Somebody said in this ML; Everything over HTTP, not on IP. Frankly what I have felt like is that one. plz share your valulable views. Jiwoong
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.