Outgoing SMTP Servers

Thu Oct 27 00:04:49 UTC 2011

On 27/10/11 11:11, Mark Andrews wrote:
> In message <op.v3y8xvo6tfhldh at rbeam.xactional.com>, "Ricky Beam" writes:
>> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell at 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.