ISP port blocking practice

Fri Oct 23 03:26:36 UTC 2009

Sean Donelan wrote:
> On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>> My experience is that port 587 isn't used because ISPs block it
>> out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
>> it with a proxy that filters out the AUTH parts of the EHLO response,
>> making the whole point of using the submission service ...  pointless.
> 
> You mentioned this last June.  Can anyone else corroborate it?  Rogers
> says they don't do that, and lots of other people seem to be able to
> use port 587 on Rogers (and other ISPs) without problems.
> 
> All the cases I've looked at, where someone claimed an ISP was blocking
> port 587, it turned out to be some other problem.  The most common
> reason was related to some security software/host based firewall running
> on the user's own computer.

Please pardon my ignorance here, especially if I've mistaken context...

Although I'm not an email engineer, it was at *least* three-1/2 years
ago that we switched our users from sending on port 25, to auth over 587
('users' meaning the clients we have as an ISP/hosting company, which
can establish on 587 from within OR without our network).

Although I can recall a few edge cases that were brought to my attention
for clients (users) not able to submit from a different network, the
collateral damage has been ~1%. (ironically however, it seems as though
recently those who have gone with a 'stick' have been reporting issues,
and we've had to have them switch to port 25 on the SMTP server within
the relevant network).

I never even imagined that someone would do port 587 blocking as such.

I'll have to light up on the network of the next client that complains,
and if 587 doesn't get through, I'll start advising the helpdesk that
they should redirect the former-client to call the 'ISP'.

Someone please tell me that I'm misunderstanding something, so that I
don't feel that two years of client notices, research and
implementation, and another two years of dealing with manual support
calls because they didn't 'see' the 400 warnings of email changes wasn't
all a waste.

fwiw to keep on topic, I block all 25-in with a small exception list for
a few colo boxes, and our incoming MTA collection/filtering cluster.

This 'in' ACL is placed on all PE hardware. The incoming mail cluster is
attached to it's own PE, which ensures that everything from anywhere on
the network eventually filters through this ACL, and that the core is
always essentially clean.

I then pretty much do the same out-25 on all PE hardware. Because my
network is small, I manually/strictly manage the ACLs on any PE that is
Internet/Peer facing.

colo servers that require SMTP services is either connected to a PE
designed to allow it, or is put into a VLAN designed for such. afair, I
have only two clients remaining that I haven't forced into a /29 corner
where I can SWIP their space, thereby using the 'you're responsible'
hammer. Either way, even without the swip, I've made them well aware of
the repercussions of failing to at least be attentive.

Steve