Would like a new switch of
--smtpsendport ##
to allow the ability to change the SMTP Outgoing IP Port from 25 to a non standard IP Port.
====
We already have the switch of
--smtpport ##
to allow control of the SMTP Inbound IP Port from 25 to a non standard IP Port Listener.
by: Edward H. | over a year ago | Agents
Comments
Many SMTP relay hosts allow non standard ports to get around ISP blocks on port 25. Common ones include 587 and 2525. This is configurable on open source systems like sendmail and postfix as well as other commercial SMTP engines like exchange.
I've encountered ISPs that block port 25 out. Either send to a outside filter service or their mail servers, via the submission port 587 (RFC 6409). This was for a small business link, basically treating them the same as a home service.
+1
and more and more smarthosts /spamfilters for scanning outgoing email require to receive emails on port 587 instead of 25..
no joy to let gwia send mails to those hosts....
.. and its required / necessary by law to communicate encrypted from May 2018...
Where is this request at within the GroupWise development team? I have to install Postfix (Semdmail) on SLES to get around this GWIA limitation today. I wish the GWIA could just send outbound on another IP Port other than 25.
@Jürgen B
The submission port does not require encryption nor does encryption require this port change.
As for law, which one? any one law only applies to a portion of us, so it was rather useless to not mention which one in addition to not being relevant to this particular Idea. I might guess which regulation from the date, but that doesn't help with understanding the apparent need or scope.
@Andy:
I agree that encryption is not necesarily bound to the port, ssl works on port 25 as well. The point is, that more and more provide use different ports or block port 25. That might have a reason for them, or might not. Some of them still offer port 25 and offer use ssl/tls, most of them switch for tls/ssl over to 587 and dont allow 25 anymore. Its just a matter of fact.
Most of the other mail server around offer the use of a different (outgoing) port. Why dont groupwise offer it? Whats the big deal of implementing this?
Regulation or law, the new DSGVO it is required that email communication needs to be encrypted - thats what I was told. Maybe someone will prove this... But if you offer Managed Services, you rely sometimes on different providers - and some of them change their settings especuially to comply with the new DSGVO..
Even without the compliance thing, it looks like many provides take this step, and if you want to use a smarthost, you might end up having no (easy) possibilty to send from gwia to the host...
Microsoft Exchange has had the capability to change the Outbound SMTP IP Port since version 2000 from what I remember. 18 years ago.
@Jürgen B GWIA already has the option to force (require) SSL, so that requirement is already met. This North American understands that regulation as GDPR and it will certainly be a part of pushing all kinds of better security practices all around the world, not just in Europe. This is only one of many drivers of the increased need for outbound port control to match rfc 6409.
As to why GroupWise doesn't have the ability to control the outbound port to be able to send to different ports such as for rfc 6409 is likely because there hasn't been sufficient demand, hence this Idea. Getting more to vote for this Idea will help speed when that happens, so get your friends and colleagues to vote as clicking on that vote button is what counts. These comments are just to attempt to flesh out or validate the Idea.
yes these features would be suitable. We have providers with fixed ports like 587 ... .
We need the GroupWise administration community to Vote this Idea up so it will be included in version 18.1.0. Who would like to be the campaign manager for this Idea?
GW PM should make a list, what has Exchange and GW not. This year all my customers thinking about migration ...
SMTP between two MTAs is port 25, and port 25 only, everything else is violating RFCs. Port 587 is for authenticated clients delivering to MTAs *only*.
... so stick either with the RFC and maybe loose business opportunity or extend the functionality to support the "need" out there (could be a hint to admin that this is not rfc).
the good thing is:
AFAIK MS Office 365 does not support (yet) sending on ports other than 25, so guess what.. these providers have to offer now a separate method of sending them mail on port 25 again, otherwise they would not support Office365 users.. which did save us to continoue to use of gwia for outgoing mail...
Please name a mail provider that accepts incoming mail only on different ports than 25. No such thing exists. If you are on an ISP that blocks port 25 out, the ISP is one or more good or bad reasons to do it, and as soon as everyone starts using 587 he will block that too. Get a real ISP then that offers Internat, and not a subset thereof.
"Fixing" this by deliberately breaking RFCs and "inventing" new communication protocols is not the right way.
many (or some?) smarthosts (in our case mailassure) for outgoing antispam try to force their customers to 587. it happened to us with a new cloud product AntiSPAM/AV/Mail Archive replacing the existing one we had (because of new regualations, the provider has chosen to discontinoue the old one which did accept port 25).
As a small MSP, we were facing this problem heavily. Good luck for us that then they realized that they need to support still port 25 because of Office365 - otherwise, their respond was ".. Exchange does provide this.."
So, yes, I agreee that if its not RFC compliant, its "technically wrong", but hey - we are too small to force them to be more rfc compliant..
Many commercial intermediate virus/spam scanning services either support or require alternate ports. I use mailroute.net on port 587 myself. If the logic is that the rfc only allows port 25 for mail and mail should never be sent on anything other than port 25, then why do we support alternate incoming ports?
Name one that *requires* an alternate port. They support alternate ports because they have clients that opt to use ISPs that forbid sending of email over their (non-commercial) connects. But require? Never seen one. Such a service would be in violation of the RFCs. I really don't know if I would support them.
Also, why do we support alternate ports? For instance because you can setup a GWIA for authenticated clients only, where port 587 is absolutely ok.
i agree with massimo. there is no reason for this request. you need to understand the 2 possible ways you can use the gwia for.
1. as a smtp server which will always work on port 25.
2. as smtp client where you can change the port.
This work is planned for the 18.1 Release of GroupWise due in late second half of 2018. It was also put back to the 18.0.1 branch and is available as an FTF today. If you have upgraded to version 18.0.1 you can get the latest FTF that will have this functionality or wait for 18.1.
Much appreciated, is there any plan to port this to GW 14R2?
Note should be made of a new rfc encouraging the use of Implicit TLS
https://tools.ietf.org/html/rfc8314
This is available in 18.1 which is shipping today 10/31/2018. For customers on maintenance this should be available for download in your customer portal over the next couple of days.