On 25/10/2011 23:03, Mike Jones wrote:
On 25 October 2011 20:52, Alex Harrowell <a.harrowell@gmail.com> wrote:
Ricky Beam <jfbeam@gmail.com> wrote:
Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.)
--Ricky
Why do they do that?
If the hotel simply blocks port 25 then my email is broken, if they allow it then my email is broken (as my ISP doesn't let the hotel relay through their mail servers), however if the hotel redirects 25 to their own open relays then in theory my email should work fine.
This only works if the MUA is configured to send to an un-AUTH'd relay normally. It normally fails spectacularly when the MUA tries to present AUTH that the relay doesn't understand or accept. I know of at least one large consumer ISP that does this across their network. Their argument was that it caused less of a support overhead when they implemented since no one had to change any settings (in theory). The reality is that the support overhead just transfers to the hosting/mail provider. "I send mail via your server and you are rejecting it." And then the hosting provider gets to explain how the IAP is in fact mangling their customers mail. Spam from mis-configured and compromised hosts is a big issue and on an access network. Even worse with dynamically allocated IPs. Users dial up and inherit blacklistings from previous customers and often entire prefixes will be listed by the RBL if the snoeshow effect is big enough. I dislike the idea of blocking port 25 (though it has been effective in dealing with major outbreaks.) We ended up building an new product that works as an appliance. All port 25 is piped through and the packets are passed on un-touched. Spamminess is scored and with some clever integration with RADIUS, the score is applied to a username. If the threshold is exceeded then the user is dynamically blocked or directed to a honeypot (depending on the requirements). And if the user redials then the block follows them. After deploying that our abuse desk went quiet ;-) -- Graham Beneke