On 27/10/11 11:11, Mark Andrews wrote:
In message <op.v3y8xvo6tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell@gmail.com> wrote:>
Why do they do that? You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that. (and for the record, they were charging for that shitty network access.)
Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*." MTA == Mail Transfer Agent. You don't have to be a *server* to be a MTA. Blocking SMTP also prevents your customers running encrypted mail sessions to prevent nosy ISP's and others looking at what they are sending. With DNSSEC now being deployed and DANE being standardised, running a SMTP session with STARTTLS is being a reality.
Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to prevent customers running encrypted mail sessions? If SMTP = 25/TCP and encrypted mail sessions run on another port, they're not blocked?
Now most people don't care about this but you shouldn't have to get a business grade service just to have secure email sessions and if you want to run a SMTP server to do that you are not changing the amount of traffic going over the connection so why the hell should a ISP care. IMAP, POP, SMTP all have about the same overhead for inbound email. The majority of consumers will use the SMTP service their ISP provides and not look twice. Surely anyone wanting to use something different will either
a) run their own mail server, requiring a static IP address and simply requiring the ISP to flick a switch which says 'ok, you're not blocked for 25/TCP anymore' or b) use an alternative SMTP server on port != 25/TCP with their own authentication layer and responsibility thereof. Sometimes I feel like contributors to NANOG see themselves as typical users. IT Engineers are anything but typical when you compare to mom-and-pop-interwebs-user, and it's those very users who're likely to wind up with malware that'll be firing to random external SMTP servers via 25/TCP, delivering spam which is quite effectively blocked by a 25/TCP block. I've seen recently SMTP-AUTH sessions exploited (user/pass credentials borrowed) for spam purposes, but at least this is an order of magnitude more difficult for the spammer, and more easily tracked by the ISP than having to do IP/Time based records checks.
MUA's (mail clients) should only be connecting to specified MSA's or MTA's (mail *servers*). They should never be connecting to random MTA's (presumably for direct delivery, which is the job of an MTA not MUA.) The only people who can effectively police this is the ISP. Total utter BS.
Why? It's a reasonable position; end users in the generic sense are sending to whatever their client has set up for SMTP, fire-and-forget. Again, I feel like folks are taking their relatively complicated use-cases and treating them as the norm. Mark.