Port 25 closed on bulk sending servers

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Port 25 closed on bulk sending servers

Sam Tuke
I noticed that newsletters which I receive from large firms are typically sent from servers which have port 25 closed.

Is it common practice to close port 25 on bulk sending servers? Should we do this for Postfix servers which serve the same role? What's the advantage?

Maybe the MTAs that such senders use are so customised as to be capable of only sending, not receiving, mail?

Thanks!

Sam.
Reply | Threaded
Open this post in threaded view
|

Re: Port 25 closed on bulk sending servers

Matus UHLAR - fantomas
On 15.01.20 12:56, Sam Tuke wrote:
>I noticed that newsletters which I receive from large firms are typically sent from servers which have port 25 closed.

I guess they are not mail servers. Not all servers have to receive mail.
Many companies have different servers for incoming mail than for outgoing
mail, webservers or whatever.

>Is it common practice to close port 25 on bulk sending servers?  Should we
> do this for Postfix servers which serve the same role?  What's the
> advantage?
>
>Maybe the MTAs that such senders use are so customised as to be capable of
> only sending, not receiving, mail?

I have asked about very similar issue a week ago. Will bump.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!
Reply | Threaded
Open this post in threaded view
|

Re: Port 25 closed on bulk sending servers

Sven Schwedas
In reply to this post by Sam Tuke
> Maybe the MTAs that such senders use are so customised as to be capable
> of only sending, not receiving, mail?

Usually, yes, these systems are typically decoupled from the firms'
"regular" emailing infrastructure (maintained by different business
units etc.) and aren't interested in receiving emails: Bulk email often
doesn't care about replies, and tends to be sent on behalf of external
clients, who are in the Reply-To/From header /if/ they care about
getting replies.

Those headers are also often completely spoofed for spam emails, so
testing if /that/ email server is reachable on port 25 doesn't tell you
much either.

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
[hidden email] | ☎ +43 680 301 7167
TAO Digital   | Teil der TAO Beratungs- & Management GmbH
Lendplatz 45  | FN 213999f/Klagenfurt, FB-Gericht Villach
A8020 Graz    | https://www.tao-digital.at


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Port 25 closed on bulk sending servers

@lbutlr
In reply to this post by Sam Tuke
On 15 Jan 2020, at 05:56, Sam Tuke <[hidden email]> wrote:
> I noticed that newsletters which I receive from large firms are typically sent from servers which have port 25 closed.

And this is an issue why?

> Is it common practice to close port 25 on bulk sending servers? Should we do this for Postfix servers which serve the same role? What's the advantage?

It is common to not have port 25 open on any machine that does not receive mail.

> Maybe the MTAs that such senders use are so customised as to be capable of only sending, not receiving, mail?

That is not “highly customize”; that is a very normal setup for large installs.


--
"Are you pondering what I'm pondering?"
"Well, I think so hiccup, but Kevin Costner with an English accent?”

Reply | Threaded
Open this post in threaded view
|

Re: Port 25 closed on bulk sending servers

Bill Cole-3
In reply to this post by Sam Tuke
On 15 Jan 2020, at 7:56, Sam Tuke wrote:

> I noticed that newsletters which I receive from large firms are
> typically sent from servers which have port 25 closed.
>
> Is it common practice to close port 25 on bulk sending servers?

Yes, and not only for bulk sending servers.

> Should we do this for Postfix servers which serve the same role?
> What's the advantage?

It is quite common for inbound and outbound email to be handled by
separate systems. In environments using internal mail servers that
aren't good at spam exclusion and/or have a general pattern of chronic
insecurity (e.g. Exchange) it is not uncommon to have them sending
outbound mail from behind a very strict firewall and/or NAT with no
listeners exposed to the world and to receive via a more robust platform
for dealing with mail from the Internet.

> Maybe the MTAs that such senders use are so customised as to be
> capable of only sending, not receiving, mail?

There's some of that for very large senders, but in the modern age of
almost everything being virtual, it is also just simpler to disperse
essentially independent functions onto independent systems, with each
specifically configured and scaled to their role. In DNS this has meant
splitting authoritative servers and resolvers. In email this has meant a
more diverse split, with public MXs, initial mail submission handlers,
outbound queue handlers, mailstore management & access, and internal
distribution potentially being autonomous systems. This can simplify the
configuration of each system and make securing them less challenging.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Port 25 closed on bulk sending servers

Sam Tuke
Thank you all for your insightful replies.

Sam.

On 15/01/2020 15:24, Bill Cole wrote:

> On 15 Jan 2020, at 7:56, Sam Tuke wrote:
>
>> I noticed that newsletters which I receive from large firms are typically sent from servers which have port 25 closed.
>>
>> Is it common practice to close port 25 on bulk sending servers?
>
> Yes, and not only for bulk sending servers.
>
>> Should we do this for Postfix servers which serve the same role? What's the advantage?
>
> It is quite common for inbound and outbound email to be handled by separate systems. In environments using internal mail servers that aren't good at spam exclusion and/or have a general pattern of chronic insecurity (e.g. Exchange) it is not uncommon to have them sending outbound mail from behind a very strict firewall and/or NAT with no listeners exposed to the world and to receive via a more robust platform for dealing with mail from the Internet.
>
>> Maybe the MTAs that such senders use are so customised as to be capable of only sending, not receiving, mail?
>
> There's some of that for very large senders, but in the modern age of almost everything being virtual, it is also just simpler to disperse essentially independent functions onto independent systems, with each specifically configured and scaled to their role. In DNS this has meant splitting authoritative servers and resolvers. In email this has meant a more diverse split, with public MXs, initial mail submission handlers, outbound queue handlers, mailstore management & access, and internal distribution potentially being autonomous systems. This can simplify the configuration of each system and make securing them less challenging.
>