|
Same here. I do not understand the issue of port 25 in conjunction with
spamming! It depends how the client is configured. If Kyle uses port 25 to connect to his MSA (Mail Submission Agent) the receiver's server will not see his public IP. It would be the MTA's public IP if configured correctly. I agree that for this purpose the email submission port 587 was created, but in our days port 25 does both. So it cannot be restricted on the port level if designed for two different purposes. If the ISP forces the user to use their email servers for email delivery: a) causes confusion and breaks the idea behind SPF. According to the sender policy framework you will have to add the ISPs email server in the DNS domain settings (spf record) as Reinier has mentioned. Or you leave out the SPF record completely, then there would be no point of having the SPF. Anyway, which average email user knows all that? b) If the ISP's email server relays without smtp authentication THAT is the actual evildoer. Giving spammers a free gateway to send emails without any identification. c) Every time the user changes the ISP/network he has to change the settings or maintain two smtp server profiles. I.e. one uses UTL at home and at work MTN or Orange. Each ISP forces to use his own email server. Congratulations. Good thing we still have port 587 and 465 for SSL. I had a number of people working at different locations with a laptop facing this exact challenge. c) Most of the spam comes anyway from dynamic IP addresses of an ISP's IP pool. In that way its even easier to distinguish the sender for the antispam software. Like: pool-71-108-40-184.lsanca.dsl-w.verizon.net 551-1-60-93.w86-192.abo.wanadoo.fr 213-168-8-183-dsl.est.estpak.eeOr did you ever receive a Facebook pishing attack from a Facebook server? Very unlikely, more likely you got it from estpak.ee or similar. Plus, the whole port blocking idea of ISPs actually violates the freedom of internet usage and doesn't really make sense either. Its not my intention to start such a discussion now, the net is already full of these: http://torrentfreak.com/search/isp+blocking The point is, even if everything is blocked (in/out), assuming only outgoing traffic to port 80 for web browsing is allowed (e.g. in a corporate network) AND assuming you have a box connected elsewhere in the public internet, you can route anything from and to the network you want. There goes the corporate security policy and the SPI firewall. Or like Kyle did, using a random port. The port-service associations are recommendations, nobody said we have to stick to them. The internet is the world wide wild west. Sample case: a customer providing medical services upgrades to a new software which requires remote access to the company's network to let the remote workers allow to update data on site via handhelds. Where the head quarter is located no ISP was willing to provide broadband (in Europe!!!). Apparently the building had optical fibre but would be too expensive to connect. Switching from copper to fibre is not as easy as in other countries like Uganda :-) . The only option was UMTS 3G but again no provider allows incoming traffic, outgoing obviously works. So, the internal server keeps a persistent connection to a public server elsewhere (outgoing), that server forwards incoming traffic to the internal network and voila your VPN works even including GRE packets. Of course protected with a firewall and encrypted tunnel etc. There are dedicated providers offering remote connectivity for UMTS clients in Europe. Where there is a restriction you create a market. They are actually accepted and supported by the big ISPs providing the UMTS connection. Which raises another question, why do ISPs offer site-to-site connectivity for that kind of money here in Uganda? Calling it a corporate network data plan or similar, charging each remote site big sums per month? Worst is if the ISP routes traffic through a load balancer like UTL with some of the ADSL clients. Each and every outgoing request has a different public IP address from a pool, e.g. making FTP traffic non-functional. FTP needs 2 valid connections, one for connection negotiation and the second for transmitting the data. Furthermore, that produces issues with some secure websites which glue the session cookie to the client's public IP to prevent cross site scripting attacks. Every time you log in you are lucky if the next click on the site will throw you out or you are allowed to stay. At times where a lot of request from hundreds of clients are compressed and routed through the few public IPs the load-balancer forgets the association. Which answer (port) belongs to which request. This makes website unresponsive or slow (at times). One website including all the pictures can require 20 connections (states) from one client (browser). Then you experience that 1 oder 2 pics could not be loaded, only after a refresh. Another sample case, the other way around. Infocom's Hotspot network allows DNS requests to anywhere (dest. udp port 53), not explicit to their own DNS servers. Giving the opportunity to set-up a tunnel (listening on udp port 53) on another public box, using it as gateway and surf for free on the hotpsot system. This was tested approx. 1 year ago and worked. Maybe it has been fixed by now, its 1 firewall rule. Summary, the main question: What is recommended to block and what is the best way to detect and how to restrict. There are big discussions about ISPs restricting P2P traffic via SPI. Apart of playing a cat & mouse game with the user they might restrict a service needed by a normal application. The answer of the industry is deep packet inspection. WIKI (http://en.wikipedia.org/wiki/Deep_packet_inspection): "This is in contrast to shallow packet inspection (usually called Stateful Packet Inspection) which just checks the header portion of a packet." There is even a open-source project: http://www.opendpi.org/ Regards, Rocco Actually I do not see the problem here. Only someone with the capability to configure their smtp server to listen on another port can be able to take advantage of this kind of setting. In which case, any spam they may send will go out with the source as their smtp server not the ORANGE 3G network. |
_______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The List's Host is not responsible for them in any way. ---------------------------------------
